Компьютерные сети. 6-е изд.

3.5. Практическое использование протоколов канального уровня

Для связи компьютеров в пределах одного здания широко применяются локальные сети, однако большинство глобальных сетей построено на линиях «точка-точка». С локальными сетями мы познакомимся в главе 4. Здесь рассмотрим три наиболее распространенных случая использования протоколов канального уровня в двухточечных каналах интернета. Первый случай — передача пакетов по оптоволоконным каналам SONET. Такие каналы широко применяются, например, для соединения маршрутизаторов, установленных в разных концах сети провайдера. Вторым примером является использование каналов ADSL в пределах локального абонентского шлейфа телефонной сети. Наконец, мы обсудим применение каналов DOCSIS в пределах локального шлейфа кабельной сети — с их помощью к интернету подключаются миллионы отдельных пользователей и компаний.

Чтобы установить такие типы соединений, требуются не только двухточечные каналы, но также телефонные и кабельные модемы, арендованные линии и т.д. Для пересылки пакетов используется стандартный протокол двухточечного соединения PPP (Point-to-Point Protocol). PPP описан в стандарте RFC 1661 и доработан в более поздних документах: RFC 1662 и др. (Симпсон; Simpson, 1994a, 1994b). В каждой из трех разновидностей каналов — SONET, ADSL и DOCSIS — он применяется по-разному.

3.5.1. Передача пакетов по каналам SONET

SONET, с которым мы познакомились в разделе 2.5.3, — это протокол физического уровня, наиболее часто используемый в оптоволоконных каналах, которые составляют магистраль различных коммуникационных сетей, включая телефонную. SONET обеспечивает строго определенную скорость передачи данных (например, 2,4 Гбит/с в канале OC-48). Поток битов организован в виде пакетов фиксированного размера, которые посылаются каждые 125 мкс, независимо от наличия в них пользовательских данных.

Чтобы передавать пакеты по таким каналам, необходим некоторый механизм формирования фреймов, способный отличать возникающие иногда пакеты от непрерывного потока битов, в котором они передаются. Для этого на IP-маршрутизаторах работает протокол PPP, как показано на илл. 3.23.

Илл. 3.23. Передача пакета по каналам SONET. (а) Стек протоколов. (б) Взаимоотношения между фреймами

PPP — это улучшенный вариант более простого интернет-протокола для последовательной линии SLIP (Serial Line Internet Protocol). Он обнаруживает ошибки, поддерживает несколько протоколов, разрешает аутентификацию и выполняет ряд других задач. Благодаря широкому набору параметров PPP может использоваться в качестве трех основных методов.

1. Метод формирования фреймов, однозначно обозначающий конец одного фрейма и начало следующего. Формат фреймов также обеспечивает обнаружение ошибок.

2. Протокол управления каналом LCP (Link Control Protocol), позволяющий устанавливать соединения, тестировать их, договариваться о параметрах использования и снова отключать их, когда они не нужны.

3. Способ договориться о параметрах сетевого уровня независимо от используемого в нем протокола. Данный метод состоит в том, что для каждого поддерживаемого сетевого уровня имеется свой сетевой протокол управления NCP (Network Control Protocol).

Чтобы не изобретать велосипед, для PPP был выбран формат фрейма, близкий к формату высокоуровневого протокола управления каналом HDLC (High-level Data Link Control), некогда популярного представителя раннего семейства протоколов.

В отличие от бит-ориентированного протокола HDLC, PPP является байт-ориентированным. В частности, в PPP применяется байт-стаффинг, поэтому все фреймы состоят из целого числа байтов. HDLC использует бит-стаффинг; это позволяет отправить фрейм размером, к примеру, 30,25 байта.

Существует второе важное отличие. HDLC предоставляет надежную передачу за счет метода «раздвижного окна», подтверждений и тайм-аутов, как мы видели выше. PPP также может обеспечить надежность в зашумленной среде, например в беспроводных сетях; детали определены в стандарте RFC 1663. Однако на практике это применяется редко. Вместо этого для предоставления службы без установки соединения и без подтверждений в интернете применяется ненумерованный режим.

Формат фрейма PPP показан на илл. 3.24. Все PPP-фреймы начинаются со стандартного флагового байта протокола HDLC 0x7E (01111110). Если этот байт встречается в поле Payload, он предваряется управляющим байтом 0x7D, а следующий за ним представляет собой экранированный байт, сложенный по модулю 2 со значением 0x20 (при этом переключается пятый бит). Например, 0x7D 0x5E — это управляющая последовательность для флагового байта 0x7E. Это означает, что начало и конец фрейма можно найти, просто просканировав содержимое на наличие байта 0x7E. Больше он нигде встречаться не будет. Правило удаления заполняющих битов при получении — найти значение 0x7D, удалить его, а следующий байт сложить по модулю 2 со значением 0x20. Кроме того, между фреймами необходим только один флаговый байт. Несколько флаговых байтов могут применяться для заполнения канала при отсутствии фреймов данных для отправки получателю.

Илл. 3.24. Полный формат фрейма PPP для работы в ненумерованном режиме

После стартового фрейма идет поле Address (Адрес), которому всегда присваивается двоичное значение 11111111; это означает, что все станции должны принимать этот фрейм. Использование такого значения позволяет избежать необходимости назначать адреса передачи данных.

За полем адреса следует поле Control (Управляющее поле), его значение по умолчанию равно 00000011. Это число означает ненумерованный фрейм.

Так как по умолчанию поля Address и Control являются константами, протокол LCP позволяет двум сторонам договориться о возможности пропустить оба поля и сэкономить таким образом по 2 байта на фрейм.

Четвертое поле фрейма PPP — Protocol (Протокол). Оно определяет тип пакета, который содержится в поле Payload. Номера, начинающиеся с бита 0, отведены для IP версий 4 и 6, а также других протоколов сетевого уровня, таких как IPX и AppleTalk. С бита 1 начинаются коды, используемые в конфигурационных протоколах PPP, включая LCP и различные NCP для каждого поддерживаемого протокола сетевого уровня. Размер поля Protocol по умолчанию составляет 2 байта, однако путем переговоров с помощью LCP он может быть уменьшен до одного байта. Вероятно, разработчики перестраховались на случай, если когда-либо будет использоваться более 256 протоколов.

Поле Payload может быть переменной длины, вплоть до некоторого оговоренного максимального значения. Если размер не определен во время установки соединения при помощи LCP, то по умолчанию используется длина 1500 байт. При необходимости данные пользователя могут дополняться специальными символами.

Следом за Payload располагается поле Checksum (Контрольная сумма). В обычном состоянии оно занимает 2 байта, но в случае необходимости по договоренности может занимать четыре. Четырехбайтная контрольная сумма фактически представляет собой 32-битный код CRC, образующий многочлен которого представлен в конце раздела 3.2.2. Двухбайтная контрольная сумма также является стандартным кодом CRC.

Итак, PPP — это механизм формирования фреймов, работающий со многими протоколами в разных физических средах. Варианты использования PPP в сетях SONET описаны в стандарте RFC 2615 (см. Малис и Симпсон; Malis and Simpson, 1999). Применяется четырехбайтная контрольная сумма, так как она считается основным способом распознавания ошибок передачи на физическом, канальном и сетевом уровнях. Рекомендуется не сжимать поля Address, Control и Protocol, так как каналы SONET и так работают на относительно высокой скорости.

Есть и еще одна интересная особенность. Перед тем как попасть в поток данных SONET, полезная информация протокола PPP скремблируется (как описано в разделе 2.4.3). При скремблировании данные складываются по модулю 2 с длинной псевдослучайной последовательностью. Только после этого они пересылаются получателю. Проблема в том, что потоку данных SONET для успешной синхронизации требуется частая смена значений битов. В колебаниях голосового сигнала это происходит естественным образом, но при пересылке данных пользователь сам выбирает, какую информацию передать. Он может, к примеру, отправить длинную последовательность нулей и вызвать тем самым проблемы. Благодаря скремблированию вероятность такого развития событий ничтожно мала.

Перед тем как передавать фреймы PPP по каналу SONET, необходимо установить и настроить соединение PPP. Этапы, через которые проходит линия связи при ее установлении, использовании и разъединении, показаны на илл. 3.25.

Илл. 3.25. Диаграмма состояний установки и разрыва соединения PPP

Изначально линия в состоянии DEAD (отключена), то есть соединения на физическом уровне не существует. После создания физического соединения линия переходит в состояние ESTABLISH (установление соединения). В этот момент начинаются переговоры о параметрах с помощью протокола LCP. Узлы PPP обмениваются пакетами LCP (они содержатся в поле Payload фрейма PPP). Это необходимо для выбора из перечисленных выше параметров PPP. Инициирующий узел предлагает варианты, а отвечающие узлы либо соглашаются с ними, либо отвергают частично или полностью. Они также могут делать свои предложения.

При успешном результате переговоров линия переходит в фазу AUTHENTICATE (аутентификация). Теперь обе стороны по желанию могут проверить, кем является собеседник. После успешной аутентификации в фазе NETWORK (сеть) происходит обмен пакетами NCP для настройки сетевого уровня. NCP сложно описать общими словами, так как каждый из них отличается в зависимости от конкретного протокола сетевого уровня и поддерживает конфигурационные запросы, характерные только для него. Например, для IP наиболее важной задачей является назначение IP-адресов собеседникам на обоих концах линии.

Когда линия переходит в фазу OPEN (открыть), можно начинать передачу данных. Именно в этой фазе IP-пакеты пересылаются в PPP-фреймах по линии SONET. Когда передача данных закончена, линия переходит к фазе TERMINATE (завершить), а затем снова в состояние DEAD (выключено), когда физическое соединение разрывается.

3.5.2. ADSL

ADSL (Asymmetric Digital Subscriber Line — асимметричная цифровая абонентская линия) соединяет миллионы домашних пользователей с интернетом на скоростях, равных нескольким мегабитам в секунду. Для этого используются те же телефонные провода, по которым предоставляются услуги традиционной телефонии. В разделе 2.5.2 описано, как на стороне пользователя устанавливается устройство под названием DSL-модем. Он отправляет биты по абонентскому шлейфу, адресуя их DSLAM (DSL Access Multiplexer — мультиплексор доступа DSL), установленному в местном офисе телефонной компании. Теперь мы более подробно рассмотрим процесс передачи пакетов по каналам ADSL.

Общая схема работы протоколов и устройств показана на илл. 3.26. В разных сетях применяются различные протоколы, поэтому для демонстрации мы выбрали наиболее популярный сценарий. Домашний компьютер пользователя посылает IP-пакеты DSL-модему, используя канальный уровень, например сеть Ethernet. Затем DSL-модем отправляет IP-пакеты по абонентскому шлейфу на устройство DSLAM с помощью протоколов, которые мы рассмотрим далее. На стороне DSLAM или подключенного к нему маршрутизатора (в зависимости от реализации) IP-пакеты извлекаются, поступают в сеть провайдера и достигают точки назначения в интернете.

Илл. 3.26. Стек протоколов ADSL

Показанные на илл. 3.26 протоколы, работающие в канале ADSL, начинаются с низшего, физического уровня. Они основаны на мультиплексировании с ортогональным делением частот (также известном как цифровая многоканальная тональная модуляция), с которым мы познакомились в разделе 2.4.4. Ближе к вершине стека, под сетевым уровнем IP, находится PPP. Это тот же самый протокол PPP, который мы изучили при обсуждении передачи пакетов по сетям SONET. Он точно так же устанавливает и настраивает связь для передачи IP-пакетов.

Между ADSL и PPP находятся ATM и AAL5. Это новые протоколы, с которыми мы ранее не встречались. Протокол асинхронной передачи данных ATM (Asynchronous Transfer Mode) был разработан в начале 1990-х годов и широко рекламировался при первом запуске. Была обещана сетевая технология, которая решит все мировые телекоммуникационные проблемы, объединив голос, текстовые данные, кабельное телевидение, телеграф, почтовых голубей, связанные нитью консервные банки и все остальные способы передачи информации в единую интегрированную систему, способную удовлетворить любые требования пользователей. К сожалению, ожидания не оправдались. В целом ATM столкнулся с теми же проблемами, о которых мы упомянули в разговоре о протоколах OSI: неудачное время, плохая архитектура и реализация, а также политические нюансы. Тем не менее ATM все же добился большего успеха, чем OSI. И хотя он не покорил весь мир, его активно применяют в некоторых линиях широкополосного доступа, таких как DSL, и особенно в WAN-каналах телефонных сетей.

ATM представляет собой канальный уровень, основанный на пересылке ячеек (cells) информации фиксированной длины. «Асинхронная передача» означает, что нет необходимости отправлять ячейки постоянно, как это происходит с битами в синхронных линиях типа SONET. Ячейки пересылаются только тогда, когда имеется готовая к передаче информация. ATM — это технология, ориентированная на установление соединения. В заголовок каждой ячейки встраивается идентификатор виртуального контура (virtual circuit), и устройства используют этот идентификатор для пересылки ячеек по маршрутам внутри установленных соединений.

Длина каждой ячейки составляет 53 байта: 48 байт пользовательских данных плюс 5 байт заголовка. Используя ячейки небольшого размера, ATM гибко разделяет полосу пропускания физического канала между разными пользователями. Это полезно, например, при одновременной передаче голоса и данных по одному каналу. При пересылке фрагментов голосовой информации не возникнет длинных задержек благодаря отсутствию больших пакетов данных. Нестандартный выбор длины ячейки (сравните с более распространенным значением — степенью двойки) отражает важность политической составляющей разработки протокола. 48 байт под полезную информацию — это компромисс между 32-байтными ячейками, которые хотела использовать Европа, и 64-байтными, за которые голосовали США. Краткое описание протокола представили Сиу и Джейн (Siu and Jain, 1995).

Для пересылки данных по сети ATM необходимо преобразовать их в последовательность ячеек. Преобразование выполняется на уровне адаптации протокола ATM путем сегментации и обратной сборки. Для разных служб, пересылающих различную информацию (от периодических голосовых сэмплов до пакетных данных), были определены несколько уровней адаптации. Основной, используемый для пакетных данных — это уровень адаптации ATM 5 (ATM Adaptation Layer 5, AAL5).

Фрейм AAL5 показан на илл. 3.27. Роль заголовка в нем исполняет трейлер (AAL5 trailer), содержащий сведения о длине (Length), а также 4-байтный код CRC для обнаружения ошибок. Разумеется, это тот же самый CRC, используемый протоколом PPP и сетями стандарта IEEE 802, такими как Ethernet. Ван и Кроукрофт (Wang and Crowcroft, 1992) продемонстрировали, что это достаточно сильная конфигурация для обнаружения нетрадиционных ошибок, например сбоя в порядке следования ячеек. Помимо пользовательских данных (AAL5 payload), во фрейме AAL5 есть биты заполнения (Pad). Они дополняют общую длину, чтобы она была кратной 48 байтам. Таким образом, фрейм можно поделить на целое число ячеек. Хранить адреса внутри фрейма не нужно, так как идентификатор виртуального контура, имеющийся в каждой ячейке, не даст ей заблудиться и приведет к нужному получателю.

Илл. 3.27. Фрейм AAL5, содержащий данные PPP

Итак, мы познакомились с протоколом ATM. Осталось только обсудить, как его задействует протокол PPP при ADSL-подключении. Это делается с помощью еще одного стандарта, который так и называется — PPP с использованием ATM (PPP over ATM, PPPoA). В действительности данный стандарт нельзя назвать протоколом (поэтому на илл. 3.26 его нет). Скорее это спецификация, описывающая, как одновременно применять протокол PPP и фреймы AAL5. Она описана в стандарте RFC 2364 (см. Гросс и др.; Gross et al., 1998).

Пользовательские данные AAL5 содержат только два поля PPP: Protocol и Payload, как показано на илл. 3.27. Поле Protocol сообщает устройству DSLAM на другом конце линии, чем являются эти пользовательские данные: пакетом IP, LCP или другого протокола. Принимающая сторона знает, что ячейки содержат информацию PPP, так как виртуальный контур ATM настраивается соответствующим образом.

Для фрейма AAL5 механизмы формирования фрейма PPP не требуются, всю работу выполняют ATM и AAL5. Дополнительно создавать фреймы было бы попросту бессмысленно. Код CRC протокола PPP также не нужен, поскольку AAL5 включает такой же CRC. Механизм выявления ошибок дополняет кодирование физического уровня, применяемое в каналах ADSL (код Рида — Соломона для исправления ошибок и 1-байтный CRC для распознавания оставшихся отклонений, не выявленных другими способами). Это куда более сложный механизм устранения ошибок, чем тот, что применяется при пересылке данных в сетях SONET. Причина проста — линии ADSL гораздо зашумленнее.

3.5.3. DOCSIS

Согласно общепринятому определению, стандарт передачи данных по сетям кабельного телевидения по коаксиальному кабелю (Data Over Cable Service Interface Specification, DOCSIS) подразумевает наличие двух компонентов — физического уровня (PHY) в том виде, как он был описан в предыдущей главе27, и уровня управления доступом к среде (Media Access Control, MAC), представленный в главе 4. DOCSIS находится выше физического уровня и берет на себя решение таких задач сетевого уровня, как распределение пропускной способности для восходящего и нисходящего потока (управление потоком), формирование фреймов и исправление ошибок (конечно, иногда это происходит на физическом уровне). Все эти концепции уже были рассмотрены ранее в данной главе. Далее мы узнаем, как эти задачи решаются в протоколе DOCSIS.

Фрейм DOCSIS содержит разнообразную информацию, включая показатели качества обслуживания и служебные данные о фрагментации или конкатенации фреймов. Однонаправленная последовательность фреймов называется служебным потоком (service flow). Основные служебные потоки передают управляющие сообщения от головной станции кабельных модемов (Cable Modem Termination System, CMTS), расположенной в офисе оператора кабельной сети, к каждому модему. Служебный поток снабжается уникальным идентификатором и часто ассоциируется с одним из следующих классов обслуживания: «наилучший из возможных», «опрос» (при котором кабельный модем явным образом запрашивает полосу пропускания) и «предоставление сервиса» (модем передает пакеты данных с гарантированным сроком их получения). Основным является служебный поток по умолчанию, в котором передаются все фреймы, которые не были отнесены к какому-либо другому сервису. Во многих конфигурациях широкополосного доступа используются только исходящий и входящий служебные потоки по умолчанию — между кабельным модемом и головной станцией, в которых передается весь пользовательский трафик и все управляющие сообщения. Сети DOCSIS были изначально разработаны с расчетом на то, что данные будут в основном передаваться во входящем направлении. Характер трафика некоторых современных приложений, например приложений для видеоконференций, уже не укладывается в эту схему; в то же время новейшие облачные игровые сервисы (такие, как Stadia, GeForce Now, xCloud) могут использовать входящий трафик в еще больших масштабах, обеспечивая непрерывную потоковую передачу данных со скоростью до 30–35 Мбит/с.

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

До версии DOCSIS 3.1 пакеты входящего потока разделялись на фреймы MPEG длиной 188 байт; при этом каждый фрейм содержал 4-байтный заголовок и пользовательские данные в 184 байта (так называемый уровень конвергенции MPEG). Помимо самих данных, головная станция периодически отправляет модему управляющую информацию о ранжировании, выделении каналов и других задачах, связанных с их распределением. Эти задачи выполняются уровнем управления доступом к среде (MAC). В целях совместимости версия DOCSIS 3.1 по-прежнему поддерживает данный уровень конвергенции, но он больше не используется для входящей передачи данных.

Канальный уровень DOCSIS организует передачу в соответствии с профилями модуляции (modulation profiles). Профиль модуляции представляет собой список заказов модуляции (то есть битовых нагрузок), сопоставленных с поднесущими OFDM. При нисходящей передаче головная станция может использовать отдельный профиль для каждого кабельного модема, но обычно он используется для целой группы модемов с одинаковыми или близкими параметрами производительности. Принимая в расчет идентификационные данные служебного потока и параметры QoS, канальный уровень (в DOCSIS 3.1), теперь называемый уровнем конвергенции (convergence layer), группирует пакеты с одинаковым профилем в один буфер пересылки. Обычно для каждого профиля отводится отдельный буфер небольшого размера во избежание значительной задержки. Затем алгоритм формирования кодовых слов преобразует фреймы DOCSIS в соответствующие кодовые слова с упреждающим исправлением ошибок (FEC). При этом он извлекает пакеты из буферов разных профилей, сменяя буфер на границе каждого кодового слова. В кодировке FEC фрейм DOCSIS выглядит как поток битов, а не как последовательность байтов. DOCSIS использует кодовые слова LDPC. В случае входящей передачи полное кодовое слово может содержать до 2027 байт, где 1799 байт (или меньше) служат для передачи данных, а 225 байт — для проверки четности. В каждом байте фрейма DOCSIS первым передается самый младший бит. Когда значение занимает несколько байтов, старшие байты передаются перед младшими — такой способ упорядочения называется сетевым порядком (network order). На головной станции также применяется байт-стаффинг: при отсутствии фреймов DOCSIS в нисходящем потоке станция вставляет заполненные нулями поднесущие в символы OFDM или просто вставляет последовательности единиц в кодовые слова, как показано на илл. 3.28.

Начиная с версии 3.0, DOCSIS поддерживает технологию связывания каналов (channel bonding), которая позволяет одному абоненту использовать сразу несколько исходящих и входящих каналов. Данный подход представляет собой разновидность агрегации каналов (link aggregation) — объединения нескольких физических соединений (или портов) в одно логическое. В версии DOCSIS 3.0 можно связать до 32 входящих и до 8 исходящих каналов шириной 6–8 МГц. Версия DOCSIS 3.1 предоставляет такие же возможности связывания, но каналы могут быть гораздо шире — до 192 МГц при входящей и до 96 МГц при исходящей передаче; в DOCSIS 3.0 эти цифры составляют 6–8 МГц и до 6,4 МГц соответственно. Кроме того, модем с поддержкой DOCSIS 3.1 может связывать каналы разных типов (например, один канал OFDM шириной 192 МГц и четыре канала SC-QAM шириной 6 МГц).

Илл. 3.28. Преобразование фрейма DOCSIS в кодовые слова

V — значение; Resv — зарезервировано; PDU Ptr — указатель протокольного блока данных; End of previous PDU — конец предыдущего протокольного блока данных; Start of Next PDU — начало следующего протокольного блока данных; CW header — заголовок кодового слова; Payload — пользовательские данные; BCH parity — код BCH проверки на четность; LDPC parity — код LDPC проверки на четность

27 Его также иногда называют подуровнем физической среды (Physical Media Dependent, PMD).