Как PPP или Ethernet восстанавливается после ошибок?

Question

Глядя на стандарты уровня канала передачи данных, такие как PPP общий формат кадра или Ethernet , неясно, что произойдет, если контрольная сумма недействительна. Как протокол узнает, где начинается следующий кадр?

Сканирует ли он только следующее появление «флага» (в случае PPP)? Если так, что произойдет, если полезная нагрузка пакета так же будет содержать сам «флаг»? Я хочу сказать, что независимо от того, используются ли поля формирования пакетов или «длины», неясно, как восстановить поврежденные пакеты, в которых поле «длины» может быть повреждено или байты «кадрирования» могут быть частью полезная нагрузка пакета.

ОБНОВЛЕНИЕ : Я нашел то, что искал (что не совсем то, о чем я спрашивал), посмотрев «Кадрирование на основе GFP CRC». По Сети связи

Приемник GFP синхронизируется с границей кадра GFP посредством процесса с тремя состояниями. Первоначально получатель находится в состоянии поиска , где он проверяет четыре байта за раз, чтобы увидеть, равняется ли CRC, вычисленный для первых двух байтов, содержимому следующих двух байтов. Если совпадение не найдено, GFP перемещается на один байт вперед, поскольку GFP предполагает синхронную передачу октетов, заданную физическим уровнем. Когда получатель находит совпадение, он переходит в состояние pre-sync . Находясь в этом промежуточном состоянии, приемник использует предварительное поле PLI (индикатор длины полезной нагрузки), чтобы определить местоположение границы следующего кадра. Если целевое число N успешного обнаружения кадра было достигнуто, то приемник переходит в состояние синхронизации . Состояние синхронизации - это нормальное состояние, при котором получатель проверяет каждый PLI, проверяет его с помощью cHEC (проверка ошибок заголовка ядра), извлекает полезную нагрузку и переходит к следующему кадру.

Короче говоря, каждый пакет начинается с "length" и "CRC (length)". Нет необходимости экранировать символы, а длина пакета известна заранее.

Кажется, есть два основных подхода к формированию пакетов:

• схемы кодирования (бит / байты, кодирование Манчестера, 4b5b, 8b10b и т. Д.)
• неизмененные данные + контрольная сумма (GFP)

Первый безопаснее, второй эффективнее. Оба они подвержены ошибкам, если полезная нагрузка просто содержит действительный пакет, а повреждение строки приводит к тому, что исходящие байты содержат последовательность байтов «начало кадра», но это звучит крайне маловероятно. Трудно найти точные цифры для надежности GFP, но многие современные протоколы, похоже, используют его, поэтому можно предположить, что они знают, что делают.

Answer 1

Как PPP, так и Ethernet имеют механизмы для кадрирования, то есть для разбиения потока битов на кадры таким образом, что, если приемник теряет отслеживание того, что к чему, он может уловить в начале следующего кадра , Они расположены прямо в нижней части стека протоколов; все остальные детали протокола построены на идее фреймов. В частности, преамбула, LCP и FCS находятся на более высоком уровне и не используются для управления кадрированием.

PPP, по последовательным каналам, таким как dialup, создается с использованием HDLC-подобного кадрирования . Значение байта 0x7e, называемое последовательностью флага, указывает начало кадра. Кадр продолжается до следующего байта флага. Любое вхождение байта флага в содержимом кадра исключается. Экранирование выполняется записью 0x7d, известного как управляющий управляющий байт, за которым следует байт, который должен быть экранирован xor'd с 0x20. Последовательность флага экранируется до 0x5e; Сам управляющий escape также должен быть экранирован до 0x5d. Другие значения также могут быть экранированы, если их присутствие нарушит модем. В результате, если получатель теряет синхронизацию, он может просто читать и отбрасывать байты, пока не увидит 0x7e, и в этот момент он снова узнает, что находится в начале кадра. Содержимое кадра затем структурируется, содержит несколько странных небольших полей, которые на самом деле не важны, но сохраняются из более раннего протокола IBM, наряду с пакетом PPP (называемым блоком данных протокола, PDU), а также проверкой кадра. последовательность (FCS).

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

Стандартная (10 Мбит / с) сеть Ethernet кодируется с использованием вещи, называемой Манчестерское кодирование , в которой каждый передаваемый бит представляется в виде двух последовательных уровней в строке таким образом, что всегда переход между уровнями в каждом бите, который помогает приемнику оставаться синхронизированным. Границы фрейма обозначаются нарушением правила кодирования, что приводит к тому, что бит остается без перехода (я читал это в книге несколько лет назад, но не могу найти цитату в Интернете - я могу ошибаться по этому поводу). По сути, эта система расширяет двоичный код до трех символов - 0, 1 и нарушение.

Быстрый (100 Мбит / с) Ethernet использует другую схему кодирования, основанную на коде 5b / 4b , где группы из четырех битов данных (nybbles) представлены как группы из пяти битов в проводе и передается напрямую, без манчестерской схемы. Расширение до пяти битов позволяет выбрать 16 используемых шаблонов, чтобы выполнить требование частых переходов между уровнями, опять же, чтобы помочь приемнику оставаться синхронизированным. Тем не менее, еще есть место для выбора некоторых дополнительных символов, которые могут быть переданы, но не соответствуют значению данных, фактически расширяя набор nybbles до двадцати четырех символов - nybbles от 0 до F и символы, называемые Q, I , J, K, T, R, S и H. Ethernet использует пару JK, чтобы отметить начало кадра, и TR, чтобы отметить конец кадра.

Gigabit ethernet аналогичен быстродействующим Ethernet, но с другой схемой кодирования - версии для оптоволокна используют код 8b / 10b вместо кода 5b / 4b, а версия для витой пары использует некоторые очень сложное расположение двоичного кода, которое я не очень понимаю. Оба подхода дают один и тот же результат, то есть способность передавать либо байты данных, либо один из небольшого набора дополнительных специальных символов, и эти специальные символы используются для кадрирования.

Вдобавок к этой базовой структуре кадрирования существует фиксированная преамбула, за которой следует разделитель кадров, и некоторые поля управления различной бессмысленности (привет, LLC / SNAP!). Допустимость этих полей может использоваться для проверки кадра, но они не могут использоваться для определения кадров самостоятельно.

Answer 2

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

PPP и Ethernet ищут сигнал начала следующего кадра. В случае Ethernet это преамбула, последовательность из 64 чередующихся битов. Если Ethernet-декодер видит это, он просто предполагает, что то, что следует, является кадром. Захватив биты и проверив, совпадает ли контрольная сумма, он решает, имеет ли он действительный кадр.

Что касается полезной нагрузки, содержащей FLAG, в PPP для этого используется дополнительный байт, чтобы предотвратить такую ​​неправильную интерпретацию.

Answer 3

Насколько мне известно, PPP поддерживает только обнаружение ошибок и не поддерживает какие-либо формы исправления ошибок или восстановления.

Резервное копирование Cisco здесь: http://www.cisco.com/en/US/docs/internetworking/technology/handbook/PPP.html

Answer 4

В этом разделе Активация линии PPP в Википедии описываются основы RFC 1661. Последовательность проверки кадра используется для обнаружения ошибок передачи в кадре (описано в предыдущем разделе «Инкапсуляция»).

Диаграмма из RFC 1661 на этой странице Википедии описывает, как фаза сетевого протокола может перезапуститься с установлением соединения при ошибке.

---

Кроме того, заметки со страницы Cisco, на которые ссылается Suvesh.

Протокол PPP Link-Control

PPP LCP предоставляет метод установления, настройки, обслуживания и разрыва соединения точка-точка. LCP проходит четыре отдельные фазы.

Сначала происходит установление соединения и согласование конфигурации. Перед обменом дейтаграммами любого сетевого уровня (например, IP) LCP сначала должен открыть соединение и согласовать параметры конфигурации. Этот этап завершается, когда кадр подтверждения конфигурации был отправлен и получен.

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

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

Наконец, прекращается соединение. LCP может прекратить связь в любое время. Обычно это делается по запросу пользователя, но может произойти из-за физического события, такого как потеря несущей или истечение таймера простоя.

Существует три класса кадров LCP. Фреймы установления связи используются для установления и настройки связи. Фреймы завершения соединения используются для завершения ссылки, а фреймы обслуживания ссылки используются для управления и отладки ссылки.

Эти кадры используются для выполнения работы каждого из этапов LCP.