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

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

В принципе, никто нас не заставляет ограничиваться только ноликами-единичками. Гипотетически мы можем договориться, что мы за один заход, за один квант времени будем по одному проводу или по одной среде передачи данных передавать сразу несколько, допустим, единиц информации, несколько бидиков. И, например, если мы используем гигабит по меди, так оно и происходит. Мы в единицу времени одновременно по разным парам передаем несколько одновременно битов и принимаем несколько битов тоже одновременно. Поэтому там оно выстреливается, если хотите, пачками из отдельных битиков. И вот когда мы передаем за единицу времени какой-то набор данных, обычно для него, для набора данных есть специальное обозначение — символ. Вот если мы передаем символ, он может быть из одного битика или из двух битиков или из четырех. В этом смысле интересная штука Wi-Fi. То есть в некоторых стандартах Wi-Fi символ, который вы будете передавать, он состоит из 11 битов. Такая вот хитрая штука бывает. Причем некоторые из этих битиков могут потеряться по дороге, и достаточно, чтобы лишь небольшое количество из них дошло, чтобы получатель понял, чего вы имеете в виду.

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

То есть будет выполнять что-то типа коммутации. И вот эту вот самую коммутацию можно будет организовать с использованием разных схем. Если мы говорим про Ethernet, например, с коммутацией, там чаще всего коммутация осуществляется таким образом, чтобы было полно связное взаимодействие между всеми устройствами. Как правило, если мы говорим про 802.3 сети, про Ethernet, то вот как раз там любой узел может отправить кадр любому другому узлу, и получатель, соответственно, в любом случае должен будет услышать, что вы такое передаете. За некоторыми исключениями в Ethernet чаще всего такое взаимодействие есть. Может быть такое, что у вас будет какой-то канал, какой-то способ передачи данных по какой-то среде передачи данных, в рамках которого вы не сможете обеспечить полно связное взаимодействие. То есть, например, таким типом взаимодействия отличался в свое время FrameRelay, стандарт организации канала, который как раз был коммутируемый, и мы про него чуть дальше поговорим. Но в рамках взаимодействия FrameRelay не обязательно любой узел мог иметь возможность связи с любым другим узлом.

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

Это будет, в частности, протокол PPP и различные варианты связи, которые этот самый PPP будут использовать. То есть это какие-то туннели могут быть, может быть PPTP, может быть L2TP. И, кроме того, это могут быть какие-то другие типы туннелей, которые физически канал не образуют, но при этом получается что-то типа логического канала, который фактически может быть использован точно так же, как отдельный выделенный провод. Сюда имеет смысл отнести туннели IPIP, GRE, ну и уже упоминавшиеся L2TP. Давайте поговорим про каждый из этих типов связи, типов организации канальной среды отдельно. Начнем мы с самого простого, что только есть. Это Ethernet. Придуман Ethernet на самом деле очень давно. И тот Ethernet, с которым мы работаем сегодня, тот Ethernet, который был придуман в 1974 году Роберт Адрекалфом в лабораториях Xerox, это совсем разные стандарты. Если говорить на пальцах, то вот тот Ethernet, который был придуман в 70-х годах, это был общий провод, который объединял в себе много разных участников одновременно.

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

формировали бы единую среду передачи данных. То есть у нас в какой-то момент времени один физический коаксиал стал разбиваться на несколько кусочков. Но при этом... Так, что-то меня как-то неправильно рисует все. У нас при этом есть вот здесь вот один кусочек коаксиала, здесь другой кусочек коаксиала. И есть какая-то железка, которая находится между двумя кусками коаксиала. При этом здесь у нас один домен коллизий, здесь у нас другой домен коллизий. То есть в этих кусочках коаксиала у нас по-прежнему возможно возникновение коллизий. У нас по-прежнему нельзя допускать того, чтобы два разных участника одновременно передавали данные между собой. Но при этом в разных кусках сети и в разных вот этих коаксиальных проводах одновременная передача и прием вполне себе возможна. То есть никто вам не мешает сделать так, чтобы один узел у вас передавал сигнал в одном домене коллизий, и другой узел передавал сигнал в другом домене коллизий. Это разные домены коллизий. Они не смешивают сигналы между собой. Как следствие, сигналы друг на друга не накладываются.

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

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

Если коммутатор ничего не знает о сети, он может руководствоваться следующей логикой. Если он будет пытаться прикинуться толстым желтым коаксиалом, то есть сделать так, что его вообще нет, то в этом случае, конечно, получатель точно получит те данные, которые ему предназначены. То есть если коммутатор пытается прикинуться толстым желтым коаксиалом, если коммутатор пытается сделать так, чтобы его вообще не было видно в сети, то в этом случае узлы все равно продолжат нормально работать, точно так же, как они бы работали без коаксиального провода. Но если в некоторых случаях мы сможем сказать, что некоторые данные можно в некоторые куски сети не передавать, например, у нас есть здесь узел А, есть вот здесь вот узел Б. Узел А отправляет данные узлу Б, и вот это вот устройство, которое находится на границе между двумя коаксиальными проводами, оно думает, нужно ли копию этого кадра от узла А до узла Б передавать вот в этот вот правый кусочек сети,

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

То есть он бы соединял между собой различные части сети, как будто бы эти части сети составляли бы одну большую целую сеть. При этом он бы разделял, он бы все равно сохранял преимущество, скажем, того, что у вас сеть разделена на отдельные домены коллизий. Сигнал, который передается в одном домене коллизии, сигнал, который передается в другом домене коллизии, он при этом не смешивается. Но эффективная работа будет, возможно, все равно как будто бы, если бы эти сети были в одном большом толстом желтом коаксиале. Так. Да. За счет чего все это дело будет происходить? За счет того, что у нас кадры в Эзернете будут иметь определенный формат. В абсолютно любом Эзернете, в абсолютно любом протоколе семейства Эзернет, кадры будут иметь одинаковый вид. Когда-то давным-давно форматов кадра было больше, сейчас осталось фактически только два. Эти кадры соответствуют формату E8023.2015 года выпуска.

То есть вот такой вот стандарт 8023 в редакции 2015 года. Ну, или более актуальная версия из 2018 года, там на самом деле никаких изменений в формате кадра нет. Если говорить про формат кадра, я думаю, что вы CCNA должны это помнить. Сначала идет преамбула. 7 байт чередующиеся единички-нолики. Нужна она была в свою очередь для решения давней-давней проблемы. Как синхронизировать передатчик и приемник на узлах, которые находятся в одном домене коллизий. Ну, когда-то давным-давно эта проблема была актуальна, сейчас уже не актуальна. Сегодня, по большому счету, преамбула не нужна. Но поскольку во всех-всех-всех форматах Ethernet формат кадра одинаковый, во всех стандартах Ethernet формат кадра одинаковый, то даже в современных версиях стандарта преамбула все равно есть. Потому что договорились в свое время, когда-то давным-давно, что во всех стандартах кадры одинакового формата. Дальше битик, не битик, а один байт, который будет называться Start of Frame Delimiter. Это байтик, который имеет следующее значение.

1, 0, 1, 0, 1, 0, 1, 1. Вот в отличие от 56 битов, чередующихся 1, 0, 1, 0, 1, 0 в преамбуле, 1, 0, 1, 0, вот этот байтик будет заканчиваться на битовую единичку. И он будет отделять преамбулу 63 байта чередующихся ноликов и единичек от, соответственно, боевого мяса кадра, в котором уже содержится какая-то осмысленная информация, кроме чередующихся единичка ноликов. Дальше идет 6 байт макадриса получателя, 6 байт макадриса источника, то есть кому оно идет и от кого оно идет. По большому счету в Ethernet с коаксиалами нужно было только указывать, кому оно идет, потому что когда у вас есть узел, который отправляет данные кому-то другому, он отправляет эти данные физически всем в коаксиале, и только тот, кто действительно обладает определенным IP-шником, он этот кадр будет читать. Он не зажмуривается, и он действительно читает, что дальше передается. Все остальные, а их много, должны будут зажмуриться, и чем раньше они зажмурятся, тем лучше.

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

поэтому он идет на втором месте. Дальше идет указание, что внутри лежит или сколько этого внутри лежит. Соответственно, если там лежит какое-то число, которое больше, чем 1536, то это будет распознаваться как значение Ethertype. Если там лежит число, которое меньше, чем 1500, то это трактуется как длина содержимого. И, соответственно, все, что между этими двумя значениями с 1501 до 1535, это неопределенное значение. И в трактовке 802.3 стандарта такое недопустимо. То есть, если вы видите кадр, который отправлен в 2019 году, скорее всего, там будет либо число вот здесь вот, в этом диапазоне, либо число вот в этом диапазоне. А вот этого вы никогда не увидите в норме. Если вы вдруг увидите, коммутатор просто такое значение выкинет. Ну, не коммутатор, а конечный абонент. Он скажет, я не могу прочитать, что внутри лежит. Это не длина, это не Ethertype, это вообще непонятно что. Неправильный формат кадра. Дальше.

В конце любого кадра у нас есть FrameCheckSequence 4 байта. Проставляется отправителем для того, чтобы можно было проверить, не побились ли данные по дороге. Побиться данные по дороге могли в коаксиале очень простым способом. Если у нас случалась коллизия. То есть, если прибежал какой-то набор данных, битиков, ноликов, единичек, получатель всегда проверял чек-сумму. Если чек-сумма сошлась, значит, кадр не побился по дороге, коллизия не произошла, и кадр можно отправлять дальше на проверку, на анализ. Если прибежала какая-то битовая последовательность ноликов и единичек, то, соответственно, мы читаем чек-сумму, видим, что она не сошлась, что неожидаемый результат там в итоге получается после вычисления CR32 с определенным полиномом. Мы такой кадр просто выбрасываем. Это будет означать, если мы вычислили, что какой-то кадр побился по дороге, что, скорее всего, возникла коллизия. Поэтому тот, кто захочет отправить этот кадр, он переотправит его нам. То есть, если мы видим данные, которые побились по дороге, они, скорее всего, побились из-за коллизий,

и, скорее всего, отправитель сможет их переотправить. Поэтому, когда говорят, что в Ethernet нет надежной доставки, изначально в Ethernet была надежная доставка. То есть, вероятность того, что данные просто случайно бы побились по дороге из-за каких-то наводок, она была очень и очень небольшой. В коаксиальном проводе, в толстом желтом коаксиале, данные просто так не ломались, не бились. Единственный сценарий, при котором данные могли быть повреждены, это у вас два узла устраивали коллизию. Поэтому в изначальном Ethernet-е данные всегда доставлялись надежно. Поскольку FrameCheck Sequence находится в самом конце кадра, иногда говорят, что это будет трейлер. Типа вот это вот все, типа хедер, заголовок кадра, 14 байт. А, соответственно, вот эта вот штука, это 4 байта так называемого трейлера. И получается, да, вот что у нас у кадра есть мясо кадра, вот это вот самое MAC Client Data, есть 14 байт заголовка и 4 байта хвостика. Ну, по большому счету, это не как-то ни на что не влияет.

Поэтому хотите, называйте это трейлером, хотите, не называйте. Ну, вообще оригинальное название про поле FrameCheck Sequence, FCS. Если вы указываете, что внутри лежит, то есть указываете значение EtherType, и, соответственно, вы говорите, что в этом случае вы трактуете этот кадр как кадр формата Ethernet 2. Ну, то есть это старое название Ethernet 2. В любом случае это формат кадра 802.3 комитета, 802.3 формата. Но если вы указываете значение больше, чем 1500, то вы говорите, что это будет интерпретация как тип данных передаваться. И, соответственно, если вы указываете здесь какое-то значение, например, 0800, 16-ти ричное, то, значит, дальше идет указание, что внутри лежит, это IPv4. И вот в поле Mac Client Data вы вкладываете содержимое какое-то, которое может иметь предсказуемый размер. Не меньше, чем 46 байт, не больше, чем 1500. 1500 байт ограничения связано с особенностями функций CRC32,

как считается вот этот вот самый хвостик, как считается чек-сумма. В принципе, при определенных обстоятельствах это ограничение можно будет изменить. То есть вы можете сказать, что вас не интересует 1500 байт ограничения сверху, вас интересует, например, 1550 или 1600. И в провайдерских сценариях часто приходится такое делать, часто приходится выставлять ограничения сверху немножко другим. Не 1500 байт на содержимое, а вот там 1600, например. По умолчанию чаще всего на конечном оборудовании интерфейс Ethernet настроен именно на содержимое 1500 байтовое. Ограничение снизу связано с особенностями работы с толстым-желтым коксиалом в самых первых версиях Ethernet. Ограничение снизу в 46 байт на поле содержимого, плюс 14 байт заголовка, плюс 4 байта чек-суммы, дает вам 64 байта. То есть кадр меньше, чем 64 байта быть не мог. И время, которое требовалось вам для передачи этих самых 64 бит,

по стандарту было зарезервировано для того, чтобы абсолютно любые узлы, как бы далеко они не находились в пределах какого-то разумного значения от отправителя, гарантированно успевали бы обнаружить коллизию. И гарантированно вы бы успевали обнаружить, что коллизия произошла с каким-то узлом, который находится на максимальном расстоянии от вас. Поэтому минимальный размер кадра в 64 байта был нужен именно для механизма работы с коллизиями. Если у вас коллизия произойти не может, в принципе, по большому счету, вот это вот ограничение снизу вам тоже не сильно интересно. Но опять же, в свое время договорились, что у всех стандартов Ethernet, даже тех, где коллизия произойти не может, формат кадра обязан быть одинаковый. Поэтому, несмотря на то, что коллизия произойти не может, все равно ограничение снизу в 46 байт у содержимого есть даже у современных версий. Если вы трактуете кадр как кадр формата 802.2, то есть вы указываете вот здесь какое-то число, которое меньше, чем 1500, это будет означать, что вы используете интерпретацию длины.

И, значит, здесь будет указываться размер содержимого. Размер содержимого, естественно, не может превышать эти самые 1500. Мы договорились, что если мы трактуем кадр как кадр с длиной, то, значит, здесь число, которое меньше, чем 1500. И дальше идет, собственно, мясо. Но в мясе есть то же самое ограничение от 46 до 1500 байт, как и в случае с интерпретацией Ethernet 2. И под это мясо дополнительно нужно будет еще откусить немножко данных, куда мы будем писать заголовки. Заголовки нам понадобятся, потому что если мы указали, сколько данных внутри лежит, но не указали, что внутри лежит, то нам надо будет куда-то все-таки записать, что именно мы сейчас передаем. И под это чаще всего в современном мире выделяются заголовки стандартов LLC и SNAP. Сначала идет чаще всего 3 байта LLC-шного заголовка, потом 5 байт SNAP-заголовка. В принципе, существуют протоколы, которые используют только LLC-вложения, например, Spanning 3. Ванильный Spanning 3 использует чистое LLC-шное вложение

без SNAP-а, но количество стандартов, которые бы использовало его, оно около нулевое. И в реальности, да, вы такие кадры будете встречать крайне редко. В подавляющем большинстве сценариев вы будете видеть кадры из Rnet 2. То есть IPv4, IPv6, ARP – это все кодируется как из Rnet 2. Ну и, соответственно, если у нас есть ограничения на размер поля Mac Client Data сверху и снизу, то это ограничение никуда не девается, независимо от интерпретации. То есть что вы используете здесь, интерпретацию тип, что вы используете здесь, интерпретацию DNA, вот отсюда до сюда все равно вот такое вот ограничение должно соблюдаться. От 46 до 1500 байт. Если вы должны будете куда-то внутрь этого самого поля Mac Client Data записать дополнительные заголовки, которые у вас могут занимать, например, 8 байт, 3 байт LLC плюс 5 байт SNAP-а, значит, под актуальное мясо содержимого у вас останется меньше данных, меньше размер поля с данными. Ограничение снизу 46 байт никуда не делось.

Если вы 8 байт записали заголовки, значит, вы данных полезных должны будете записать, ну, никак не меньше 38 байт. Ну, и не больше, чем 1492. В случае с интерпретацией Ethernet 2 вы можете записать в Mac Client Data больше, чем 1500 байт. Вы указываете, что здесь вы передаете, там, не знаю, 0x0800 IPv4, и дальше вы говорите, я сейчас здесь вот нафигачу 9 килобайт данных. Формально вы можете такое сделать, главное, чтобы у вас все узлы понимали, что вы такое творите. В случае с интерпретацией длины, если вы здесь указываете число, там, не знаю, 1400, вы должны будете указать, что вот все вот это вот у вас занимает 1400 байт. Нафига придумали два разных типа интерпретации? Дело в том, что если вы используете только, допустим, Ethernet 2 интерпретацию, в том виде, в котором я придумал Роберт Мэткалф, то есть вот это вот, когда вы указываете, что внутри лежит, вы должны будете не меньше, чем 46 байт, положить внутрь кадра. А иногда хочется отправить данных меньше,

чем 46 байт. Вот мы хотим отправить самый маленький IP-пакет, который мы можем сделать. Это, не знаю, пинги какие-нибудь. Вот мы должны будем 20 байт IP-заголовка положить, 4 байта ICMP-заголовка, и вот все, типа хватит. Вот нам 24 байта, в принципе, достаточно для того, чтобы попингать соседа. Ну, 28. В кадр мы не можем положить меньше 46 байт. Поэтому что мы в этом случае будем делать? Мы говорим, мы кладем содержимое 28 байт, а остальное заполняем мусором. Но получатель, когда он получит такой кусок данных, он не сможет легко определить, сколько данных мы полезных положили, а сколько данных мы добили мусором. Ну, нулями, как правило. Ему нужно будет каким-то образом это подсказать. В случае с IPv4 это легко можно сделать, потому что в заголовке IP указывается, сколько полезных данных занимает IPv4 пакет целиком. И можно будет понять, если мы получили 46 байт всего, из них 28 байт полезных и еще 18 байт мусора. Вот мы в этом случае сможем сказать, да, мы получили 46-байтовый кусок,

но из него только 28 байт. Мы видим из заголовка прочитать по факту надо, остальное читать не обязательно. В случае с некоторыми протоколами у них нет легкого указания, сколько данных прибежало. Например, тот же самый Spanning 3. Он не указывает, сколько данных передается внутри его датограммы. Поэтому если мы используем такие протоколы, которые не содержат информацию о количестве содержимого, нам нужно использовать интерпретацию с длиной. Как правило, это протоколы, которые могут отправлять данных меньше, чем 46 байт. То есть всякие служебные мелкие протокольчики, они вот как раз эту самую интерпретацию длины будут использовать. Spanning 3, CDP, VTP, вот это вот все туда вот будет относиться. Так. Если мы говорим про провайдерские сценарии, то мы можем использовать кадры формата Ethernet. То есть мы можем использовать 802.3 эти кадры либо в интерпретации типа, либо в интерпретации длины.

Но эти кадры будут коммутироваться по некоторым правилам. В LAN-сетях мы коммутируем их по правилу, каждый может отправить кадры куда угодно. В случае с провайдерскими сценариями логика, пригодная в LAN-сетях, не всегда хорошо работает. Поэтому для того, чтобы формат кадра можно было использовать именно в провайдерских сценариях, именно в сетях масштаба города, существует специальный набор техник, которые позволяют использовать кадры формата Ethernet и протоколы связи Ethernet в сетях масштаба города. Соответственно, называться такой набор методологии будет Metro Ethernet, и, соответственно, управляется он организацией, которая называется Metro Ethernet Forum, или MEF. Что этот набор методологии будет включать? Во-первых, естественно, стандарты организации каналов, которые у нас используют формат кадра Ethernet, и которые используют линии связи, которые мы обсуждали на прошлом модуле.

То есть, например, берем оптику, берем SF-пишки, и, значит, пуляем Ethernet кадры через эти SF-пишки по оптике. Понятное дело, что в LAN-сетях, допустим, дальнобойные SF-пишки на 40 километров, или там, допустим, DCG Base ZR, которые на 100 километров могут пулять, ну, это как бы в локальной сети это не используется. Используется только при расстояниях, там, 100 километров. Между городами передавать данные, да? Соответственно, это обязательно уже провайдерский сценарий. Вот если мы используем организацию канала Ethernet-овскую с использованием дальнобойных SF-пишек, с использованием дальнобойных каналов связи, то мы должны будем каким-то образом договориться, где работает еще логика, принятая в локальных сетях, и где она уже не будет работать. Соответственно, у нас начинается разделение на интерфейсы, которые смотрят на наше оборудование, и разделение на интерфейсы, которые смотрят на абонентов, которым мы уже не совсем доверяем,

потому что в локальной сети все доверяют всем. Любой узел может отправить данные любому другому. В Meta Ethernet-е у вас есть юзерские интерфейсы, User Network Interface. Это интерфейс, который смотрит на пользователя, и то, что делает пользователь, мы вообще говоря не можем проконтролировать. Он может пытаться, допустим, делать какие-то неприятные для нас вещи. Может пытаться отправлять трафик бесплатно, хотя мы собираемся брать за это деньги. Ну, в общем, на Uni Interface, если мы говорим, что у нас оборудование специальное, Meta Ethernet-овское, мы пользователю не доверяем. Мы не отправляем туда ничего лишнего, мы не принимаем ничего лишнего от этого интерфейса, и вообще мы как-то очень подозрительно к нему относимся. В то же время, Network Node Interface, NNI, это интерфейс, который смотрит на наше собственное оборудование. Например, мы берем два свеча, соединяем их между собой. В этом случае мы говорим, на этом интерфейсе любые данные, которые приходят, это данные доверенные. Мы их уже где-то проверили, и мы никаких ограничений на работу этого порта не накладываем. Вот по умолчанию

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

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

Например, тот же самый фрейм-релей. В нем была сигнализация LMI, и вы могли знать, с кем вы можете взаимодействовать до того, как вы отправили ему трафик. То есть вам со стороны сети приходило уведомление, что Вася в сети, Петя в сети. Это происходило на уровне самого канального протокола. Соответственно, метр Ethernet предполагает, что у вас аналогичная сигнализация будет работать и в Ethernet. Но не в обычном Ethernet для локальных сетей, а в Ethernet для провайдеров. И механизм, который называется OAM, это Operations, Administration and Management, или, в частности, поднабор механизмов, который называется Connectivity False Management, это как раз получение обратной связи, получение сигнализации в Ethernet о том, с кем вы можете взаимодействовать в своей сети. Если говорить про конкретно методологии метр Ethernet, они предполагают, что вы, как провайдер, с использованием этих методологий будете оказывать набор услуг, которые называются Career Ethernet. Это услуга,

которая будет называться Ethernet Virtual Private Line, или она же называется E-Line, или она же называется VPWS, Virtual Private, Virtual Psevdo Wire Service. Вот этот вот PV, псевдопровод, он как раз указывает на то, что вы по факту продаете. У вас есть один абонент, который подключается к сети в одной точке, есть другой абонент, который подключается к сети в другой точке, и вы организуете, соответственно, канал между этими двумя узлами, как будто они соединены между собой прямым проводом. Два свеча, или три свеча, или миллион свечей в этом случае прикидываются одним толстым коаксиалом, в котором есть ровно два абонента. И больше ничего. ВПВС — это вот как раз Psevdo Wire Service. Вторая услуга, которая предполагается методологией MetaRethernet и конкретным набором CarryRethernet, это Virtual Private LAN или VPLS, Virtual Private LAN Service. Она же называется ELAN. Это

по факту фактически сеть позволяет организовать передачу данных между несколькими разными абонентами. В случае с псевдопроводом мы говорим, что взаимодействие возможно только между двумя узлами, но мы можем сказать, что у нас есть вот некая сеть, и мы к этой сети готовы подключить несколько абонентов и организовать им связь между собой, как будто бы наша сеть была одним мегасвитчом, одним, ну если хотите, толстым, желтым, как сяло, ну то есть в отличие от псевдопровода у нас к этой сети может подключаться больше двух абонентов. VPLS существенно сложнее устроен по сравнению с псевдопроводом, поэтому со стороны провайдера требуется большее количество усилий для того, чтобы такую услугу предоставлять, поэтому если говорить про цены, то, соответственно, VPLS обычно сильно дороже, чем псевдопровод. Ну, тем не менее, да, это все сравнительно недешевое удовольствие. Ну и, наконец, последняя услуга, которая предусмотрена методологией Metra Ethernet и, в частности, набором услуг Carrier Ethernet будет называться E3

или Virtual Private 3. Это, по сути, разновидность ELAN, но ELAN это полносвязная топология, а E3 это неполносвязная топология. То есть у вас есть некая точка, которая может отправлять трафик кому угодно, а все остальные не могут отправлять данные никому. То есть у вас трафик может идти только в одном направлении. Эта штука исключительно полезна для телевизоров. То есть у вас есть мультикастовый поток, который вы раздаете с источника до набора получателей. При этом вы не предполагаете, что у вас получатели этого мультикастового потока могут каким-то образом влиять на источник. Этого просто не нужно. Вот. Поэтому E3 это вот как раз специальная услуга, заточенная под IPTV. В принципе, никто вас не обязывает следовать только этому набору услуг, то есть вы можете продавать любые услуги, которые захотите. Вы можете сказать, вот мы продаем именно такую услугу, которая востребована у наших абонентов. Это три участника,

которые имеют полно связанную топологию и там сто участников, которые подключаются к этим трем, которые между собой не взаимодействуют. То есть если вам вдруг почему-то это хочется продавать, подавайте, но чаще всего все равно это сводится к вот этим вот трем услугам. E-Line, E-Line или E3. И подавляющим большинству провайдеров интересно продавать именно эти три услуги. Если мы хотим работать с протоколом IP, а чаще всего провайдеры работают именно с IP, и у нас есть сети 802, то есть типа Ethernet, или Wi-Fi, или Wi-Max, или что угодно там, E-E, то в этом случае работать IP будет поверх таких сетей, как правило, с использованием служебных протоколов ARP, если мы говорим про IPv4, DHCP для автоматической настройки, опять же, если мы говорим про IPv4, и ICMP, что для IPv4, что для IPv6, опять же, для управления потоком, для управления протоколом и для решения каких-то служебных задач.

Так вот, если мы используем IPv4, то мы должны будем из IP-адресов каким-то образом получать MAC-адреса, которые как раз те самые destination и source адреса в заголовке кадра Ethernet, и для этого как раз нам будет полезен протокол ARP. ARP, адрес-резерушный протокол, очень простой служебный протокольчик, который нужен для работы IP поверх Ethernet. Если мы хотим отправить какой-то кадр известному нам IP-шнику получателю, то мы будем использовать ARP для распознавания его MAC-адреса, для того, чтобы кадр отправить именно ему содержащий нужный нам IP-пакет. Если мы хотим работать с мультикастом в IP поверх Ethernet, то у нас есть очень простое преобразование мультикастовых IP-шников в мультикастовой MAC. То есть для Unicast мы используем ARP, а для мультикаста мы используем очень простое стейтлесс-преобразование. Если у нас есть IPv4-й мультикастовый адрес, мы берем от него последние 23 бита

и приклеиваем к первым 25 битам MAC-адреса 01005E 0000. То есть, если у нас есть, например, IPv4-й пакет, который мы хотим отправить на адрес 224-005. Я думаю, что вы знаете, что это за адрес, поскольку предполагается, что вы с СНА проходили, ну, если вдруг забыли, это у SPF. Вот если мы хотим отправить пакет, например, hello-oSPF-овский, у нас есть вот такой вот IP-шник получателя, как из него сделать кадр из ARNET? Очень просто. Берем, отклеиваем последние 23 бита IP-шника. Это почти 24 бита, кроме самого старшего битика второго октета. Ну, чаще всего он как раз нулевой. И приклеиваем это к 01005E. У нас получается MAC-адрес 01005E 00005. Вот такой вот MAC-адрес. Это MAC-адрес получателя. MAC-адрес источника ставим в свой Unicast. Что внутри лежит, указываем IPv4. И дальше вкладываем IP-пакет,

который у нас был. В IPv6 все то же самое, только берем последние 32 бита и приклеиваем к 33-33. И у нас получается мультикастовый кадр, содержащий мультикастовый IPv6 пакет. Может, кому-то не понравятся странные цифры 23. Скажу, что не взяли последние 3-то октета целиком, 24 бита. Но вот кому-то в свое время показалось, что 24 бита если взять, то нам потребуется вот эта вот самая ООИшка и как бы эту ООИшку целиком не хотелось отдавать. И вот они сказали, давайте вы возьмете вот эту ООИшку и будете использовать один битик из этой ООИшки под специальные служебные нужды, которые не будут относиться к IPv4 адресу, а будут на всякий случай, а вдруг когда-нибудь потом понадобится, чтобы не выдавать потом когда-нибудь зачем отдельно другую ООИшку. Но потом не пригодилось и, соответственно, там всегда вот в этом битике ставится нолик.

Ну, такое дурацкое поведение, когда в свое время заложились, может пригодиться, по факту не пригодилось. Как в анекдоте про эстонцы и дохлую ворону. Ну, да, в IPv6 уже на такие грабли не накалывались и сразу сказали, вот у нас есть 33,33, и все ООИшки, которые начинаются на 33,33, выделили под IPv6 взаимодействие. берем последние 4 байта 32 бита IPv6 адреса, приклеиваем к 33,33 и получаем MAC адрес. Следующий протокол организации канала у нас будет называться Point-to-Point протокол. Когда-то давным-давно он прямо действительно использовался в проводах. Сегодня чаще его можно встретить не в проводах, а в виртуальных каналах типа VPN-а. Но, тем не менее, все равно нужно будет знать, как он будет устроен и почему он устроен именно таким образом. Немножко забегая в историю, опять же, когда у нас

в основном организации каналов занимались телефонисты, они использовали либо плезионосинхронную цифровую иерархию, либо синхронную цифровую иерархию, это те самые Т-1, Е-1 каналы и вот всякое вот такое вот, Е-3. И, соответственно, у вас поток битовый шел между двумя терминальными устройствами. Вы говорили, у нас есть канал производительности либо полтора мегабита, либо там 45 мегабит. И этот канал у нас строился между двумя точками. И в этом проводе, в этом канале вы передавали просто отдельные битики. Вам нужно было из этих битиков каким-то образом складывать кадры. И вот первый вариант, как организовать передачу данных просто в обычном битовом потоке, тут как раз был Point-to-Point протокол. Сегодня, понятное дело, мы можем тоже пользоваться теми же самыми каналами, теми же самыми Sonnet, SDH и все остальное. И там тоже точно так же можно использовать этот самый Point-to-Point протокол. Просто вряд ли вы будете строить новую сеть на основе Sonnet, SDH

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

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

IP-телефония. IP-телефония отличается тем, что передаются множество мелких пакетиков, в которых очень похожие или практически одинаковые заголовки идут, и дальше какое-то различающееся содержимое, которого очень мало, потому что, если у вас используется IP-телефония с хорошим каким-то кодеком, то вложение, которое вы будете передавать, оно будет вкладываться в RTP, оно, в свою очередь, вкладывается в UDP, оно вкладывается в заголовок IP, и заголовки IP-шные, UDP-шные, RTP-шные, они все одинаковые, и кадры формата из Ethernet, если вы будете в Ethernet передавать, они тоже будут одинаковые, к слову, но PPP как бы не использует заголовок Ethernet, он использует сразу вложение IP в PPP, и поэтому там IP-шный заголовок одинаковый, UDP-шный заголовок одинаковый, RTP-шный заголовок одинаковый, и различается только маленький кусочек, который занимает там буквально 20 байт, если мы говорим про передачу каких-то реальных голосовых пакетиков. Если вы используете сильное сжатие, там он может быть даже меньше,

чем 20 байт, и получается 20 байт заголовка IP, 8 байт заголовка UDP, 4 байта заголовка RTP, у вас на 20 байт мяса передается 32 байта заголовков. Если эти заголовки сжать, поскольку они все одинаковые, и просто сказать, мы передаем заголовок, который характерен для сессии номер 17, этот указатель на заголовок номер 17, он будет занимать очень мало места, и соответственно у вас из 32 байт заголовков и 20 байт мяса пакетик превращается в, например, 4 байта заголовка и 20 байт мяса. Вы просто на пустом месте на таких мелких пакетиках экономите половину полосы пропускания. Можно сжимать данные, но сжимается не так хорошо, то есть там не просто ставится ссылка на какой-то стандартный заголовок одинаковый для всех, там будет использоваться zip-подобное сжатие, и естественно, что какое-то прям сильное сжатие обеспечить сетевое устройство, как правило, будет не в состоянии,

поэтому там используется легкая степень сжатия, и если вы передаете какие-то данные, которые хорошо сжимаются zip-алгоритмами, это одна история, но чаще всего, когда мы передаем современные какие-то протоколы связи, они уже хорошо пожаты, и там дополнительного выигрыша получить не удается, поэтому шифрование данных, компрессия данных, это фишки point-to-point протокола, которые в свое время были прям очень популярны, сегодня из интересного остается только компрессия заголовков, и дальше еще у point-to-point протокола PPP есть две дополнительные штуки, которые поначалу могут взрывать мозг, первый взрыв мозга это мультилинк связь, то есть мы можем по нескольким разным каналам связи поддерживать одновременно работу одного логического соединения, мы можем например позвонить по двум модемным линиям на другую сторону

и сказать, что эти две модемные линии образуют один логический канал. Если вдруг одна линия отвалится, трафик начнет ходить через вторую. Некоторым образом это похоже на то, как выглядит допустим Ether Channel. В CISC есть такой механизм агрегирования каналов, и вот вы в Ethernet можете два провода объединить в один логический канал, и у вас два провода работают одновременно. Но Ether Channel использует по факту только один провод для передачи одного кадра. А Multilink в PPP использует все провода одновременно, все каналы одновременно для передачи каждого кадра. То есть он бьет кадр на несколько кусочков и по каждому отдельному проводу передает свой отдельный кусочек. Поэтому если у вас используется Multilink, то все каналы задействуются однаково хорошо, однаково полно. Вторая фича, которая взрывает мозг, это Multiclass. Это одновременная работа соединения, то у вас фактически образуются

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

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

Вот такие вот штуки, они в PPP есть, и они очень прикольные с точки зрения именно фич, с точки зрения управления качеством, с точки зрения управления задержками. PPP, конечно, протокол, который действительно очень-очень мощный. Для работы канала по PPP требуются служебные протоколы. Это протоколы, которые являются частью большого протокола, который называется PPP, но у них есть свое самостоятельное название, такие субпротоколы. Первый субпротокол — это LCP, Link Control Protocol. Если вы используете связь по PPP, то для того, чтобы эта связь вообще была возможна, вам будет нужно договориться о том, что вы хотите проутентифицировать соседа, вы хотите использовать шифрование, вы хотите сжимать заголовки или сжимать данные, вы хотите заказать мультилинк, вы хотите что-то еще сделать. И вот все вот эти вот ваши хотелки, которые нужны для того, чтобы согласовать параметры, необходимые для работы канала, они как раз реализуются с помощью протокола LCP. Затем, после того, как фактическая возможность передавать хотя бы какие-то данные согласовано, LCP отработал, сказал все окей.

Дальше начинают работать служебные протоколы, которые организуют возможность передачи данных каких-то уже конкретных мясных протоколов. Мясо у нас будет, какое мясо? IP, IPv4, IPv6, MPLS, CDP, IPX какой-нибудь можно вспомнить. То есть какие-то протоколы связи, которые мы можем вкладывать внутрь PPP. Но для того, чтобы передавать данные с определенным типом вложения, нужно будет сначала согласовать возможность передачи данных с этим типом вложения. И если необходимо какие-то служебные параметры настроить, то необходимо это будет сделать до начала передачи. PPP ничего без разрешения не делает. Если другая сторона не согласна принимать MPLS-ные пакеты, то вы со своей стороны их отправить просто не можете. Вы не можете сказать, а я хочу все равно отправить в MPLS в PPP-шную трубу. В Ethernet вы можете отправить, что хотите, к кому хотите. Никто вас не спросит. Хотите отправлять MPLS? Пожалуйста, отправляйте MPLS. Хотите отправлять IPv4? Пожалуйста, отправляйте IPv4. Никто не даст вам обратную связь, я у тебя этого не просил.

И вообще такого механизма обратной связи в Ethernet, как мы уже знаем, нет. Вот в PPP вы не можете, вы не имеете права отправлять данные, которые сосед в явном виде от вас не просил. Если он не сказал, дорогой сосед, отправляй мне, пожалуйста, MPLS-ные вложения, вы не можете их отправить. То есть он просто проигнорирует, если вы попытаетесь это сделать, скажет, что у вас в канале какая-то ошибка. Для работы каждого конкретного типа вложения будет использоваться свой отдельный протокол NCP, Network Control Protocol. Этих протоколов много. Для каждого типа вложения NCP свои. Есть отдельный NCP для IPv4, он называется IPCP, то есть IP Control Protocol. Есть отдельный для IPv6, IPv6-CP. Есть отдельный для MPLS-CP. Есть отдельный для IPX, IPX-CP внезапно. Есть отдельный для CDP, CDP-CP. Такое название, которое хрен выговорил. Вы говоришь, легорийский регулировщик регулировал.

Да, ну вот. Для каждого отдельного типа вложений NCP будут свои. И вы можете со своей стороны сказать, я поддерживаю вот такие NCP. Сосед скажет, я поддерживаю вот такие NCP. И вы найдете какой-то общий язык, скажете, вот мы оба поддерживаем вот такие вот типы вложений. Давайте согласуем с использованием соответствующих NCP параметры, необходимые для передачи этого типа вложений. И будем дальше уже передавать. То есть, допустим, мы со своей стороны заявили, что мы знаем, что такое IP, IPv6 и CDP. Сосед сказал, я знаю, что такое IP и MPLS. И все. И вот мы пытаемся найти какой-то общий язык. Мы говорим, и тот, и другой узел знают, что такое IP. И вот, соответственно, по IPCP начинаем настраивать друг другу какие-то необходимые параметры. Так. PPP будет использовать формат кадра, который унаследован у древнего протокола HDLC. Этот самый древний протокол HDLC никогда не использовался для передачи произвольных данных. Он был использован чаще всего в мейнфреймах для организации связи между терминалами и, собственно, самим мейнфреймом.

Терминал был устроен очень просто. Это монитор и клавиатура. И вот все, что вы на клавиатуре набираете, отправлялось в сторону мейнфрейма. Все, что вы должны были видеть на мониторе, все, соответственно, отправлялось от мейнфрейма к терминалу. В HDLC была адресация, потому что если вдруг мейнфрейм отправлял какие-то данные на терминал, нужно было, соответственно, указать, что на какой именно терминал, на какой именно монитор выводятся определенные данные. Поэтому в HDLC'шных кадрах есть адрес. в PPP, который наследует формат кадра HDLC, тоже есть поле с адресом. Но оно там не нужно, потому что PPP — это протокол point-to-point. И, соответственно, поле с адресом в PPP-шном заголовке всегда имеет предсказуемое содержимое. Это просто... Так, где мне рисовалка? Что-то меня рисовалка не рисует. Подозрительно как-то это... Да, ну вот поле с адресом... Пардон. Оно всегда имеет хорошо известное значение — FF.

То есть вот это вот однобайтовое поле, туда всегда вкладывается число 255. Это было сделано исключительно для того, чтобы не придумывать новый протокол канального уровня. Взяли протокол, который хорошо работал в мейнфреймах, и чтобы не придумывать ничего нового, этот же протокол взяли для PPP. Взяли этот формат кадра, простите. Дальше. После поле с адресом идет поле control. Control — это однобайтовое поле. Оно когда-то давным-давно указывало на то, в каком направлении данные идут. И в HDLC это поле означало, что если вы указываете единичку, данные идут от терминала к мейнфрейму. Если вы указываете двоечку, данные идут от мейнфрейма к какому-то терминалу. А если вы указываете троечку, то это значит, что какая-то хрень в ду-3 лежит, которая непонятно какая. И в PPP-шных кадрах в поле control вкладывается число 3. Это значит, что там какая-то хрень с точки зрения протокола HDLC. Действительно, так оно и есть. Мы в PPP не передаем данные от терминала к мейнфрейму

и не передаем данные от мейнфрейма к терминалу. Мы передаем просто абстрактные данные. Поле control-03 — целый байт, который у всех всегда одинаковый. Дальше идет указание, что внутри лежит. И внутри может лежать либо протокол сетевого уровня, например, IP будет передаваться, значит, там будет лежать число 21. 21-16-ричное — это, соответственно, 2 байта. И вот у IP это такое хорошо известное значение — 0021. Если там будет лежать какой-то служебный кадр, потому что в PPP есть данные, которые передаются постоянно служебные, у нас будут передаваться служебные данные согласования LCP, у нас будут передаваться данные NCP-шные, то есть это не боевые кадры, которые у нас несут в себе какую-то полезную нагрузку, а это именно служебные данные, которые узлы между собой передают для согласования параметров или для согласования работы самого канала. Вот в этом случае такие служебные кадры будут иметь поле протокол,

заполненное с использованием каких-то специальных вот значений. Если мы будем передавать какие-то кадры LCP-шные, то там будет лежать число C021. Это 16-ричное число. Оно указывает, что внутри лежит кадр формата LCP. Не кадр формата, а вложения LCP-шные. И, соответственно, этот кадр нужен для того, чтобы согласовывать работу самого канала. Например, у нас упал один из линков в мультилинке. Мы когда-то позвонили, допустим, на два модема на провайдеры, согласовали с провайдером мультилинк, и по обоим модемам начинаем передачу, а потом один модем отвалился, одно соединение завершилось. Ну, соответственно, на втором соединении надо будет сказать, что у нас теперь идет работа только по одному хвостику. Вот в этом случае мы увидим кадр формата LCP. Если у нас работают NCP, то у нас будут, опять же, специальные там указываться вложения. И для, например, IPCP мы будем видеть там число 8021.

Ну и диапазоны значений поля протокол, которые выделяются под различные нужды, они будут примерно следующие. Первая четверть, то есть с 0, 0, 0, 0 по 3FF, это протоколы вложения напрямую какие-то полезные данные передавают, передают. Дальше с 8, 0, 0, 0 по BFF, это протоколы сетевого уровня. Понятное дело, что столько вложений никогда быть не может, что не может быть такого, что у нас будет там, сколько это получается, четыре тысячи различных вариантов вложения. Ну, столько-то просто не бывает. Ну и, соответственно, все остальное, с C, 0, 0, 0 по EFF, это управляющий протокол, и там на самом деле только один протокол в ЛСП, больше других и нет. Так. Так. Так. Спасибо.