Учебно-методическии комплекс дисциплины «Компьютерные сети» для специальности 6М011100 — «Информатика» (стр. 65 )

Как следует из его названия (протокол передачи от точки к точке), РРР представляет собой протокол канального уровня, работающий на двухточечных линиях связи, то есть линиях, напрямую соединяющих два узла (RFC 1661, RFC 2153). Это может быть последовательная телефонная линия (например, соединение по модему со скоростью 56 Кбит/с), линия SONET/SDH, соединение стандарта Х.25 или канал ISDN. Как уже отмечалось выше, именно протокол РРР используется для соединения пользователя с Интернет–провайдером по телефонной линии.

Прежде чем углубиться в детали протокола РРР, рассмотрим оригинальные требования, заложенные рабочей группой IETF в идею протокола РРР (RFC 1547).

Формирование кадра. В соответствии с протоколом РРР отправитель данных должен обеспечить инкапсуляцию пакета сетевого уровня в кадре канального уровня таким образом, чтобы получатель мог определить начало и конец как кадра канального уровня, так и пакета сетевого уровня, содержащегося в кадре. Прозрачность. Протокол РРР не должен накладывать ограничения на то, как выглядят данные на сетевом уровне (данные и заголовки). Таким образом, на пример, протокол РРР не должен запрещать передачу каких бы то ни было последовательностей битов в пакете сетевого уровня. Мы скоро вернемся к этому вопросу при обсуждении байтовой подстановки Поддержка различных протоколов сетевого уровня. Протокол РРР должен обеспечивать одновременную работу различных протоколов сетевого уровня (например, IP и DECnet) в одном и том же физическом канале. Подобно тому как протокол IP обеспечивает мультиплексирование различных протоколов транспортного уровня (например, TCP и UDP) в одном сквозном соединении, протокол РРР должен обеспечивать мультиплексирование различных протоколов сетевого уровня в одном двухточечном соединении. Это требование означает, что протоколу РРР потребуется, по меньшей мере, поле типа протокола или какой–либо подобный механизм, позволяющий принимающей стороне протокола РРР демультиплексировать полученный кадр и передать его соответствующему протоколу сетевого уровня. Поддержка различных типов линий. Помимо поддержки различных протоколов более высокого уровня протокол РРР должен также обеспечивать работу на различных типах линий связи, включая последовательные (передающие по каналу в данном направлении по одному биту) и параллельные (передающие биты параллельно), синхронные (передающие сигналы таймера вместе с данными) и асинхронные, низкоскоростные и высокоскоростные, электрические и оптические линии. Обнаружение ошибок. РРР–приемник должен обнаруживать битовые ошибки в принимаемом кадре. Живучесть соединения. Протокол РРР должен уметь обнаруживать неисправность на канальном уровне (например, невозможность передачи данных по каналу) и сигнализировать об этой неисправности сетевому уровню. Согласование адресов сетевого уровня. Протокол РРР должен предоставлять механизм, позволяющий обменивающимся данными сетевым уровням (например, IP) узнавать или настраивать адреса сетевого уровня друг друга. Простота. Помимо перечисленных выше требований протокол РРР должен удовлетворять ряду дополнительных требований, самым важным из которых является «простота». В RFC 1547 говорится: «девизом двухточечного протокола должна быть простота». Трудная задача, учитывая все остальные требования к протоколу РРР! Сегодня различные аспекты этого «простого» протокола описываются более чем 50 документами RFC.

Хотя может показаться, что к протоколу РРР предъявляется очень много требований, в действительности ситуация могла быть еще сложнее. В спецификации протокола РРР также явно указываются функции, которые протокол РРР не должен реализовывать.

Исправление ошибок. Протокол РРР должен обнаруживать ошибки, но не должен исправлять их. Управление потоком. Предполагается, что РРР–приемник способен принимать кадры на полной скорости, с которой способен их переносить физический носитель. Если более высокий уровень не может принимать кадры на данной максимальной скорости, то проблема должна решаться на более высоком уровне путем отбрасывания пакетов, которые получатель не успевает обработать, или путем снижения скорости передачи данных отправителем. Таким образом, скорость передачи данных снижается не протоколом РРР, а протоколом более высокого уровня, который «спускает» пакеты протоколу РРР. Порядок доставки кадров. Протокол РРР не обязан доставлять кадры получателю в том же порядке, в котором они были отправлены. Интересно отметить, хотя подобное отсутствие требования доставки кадров с сохранением порядка следования соответствует модели обслуживания протокола IP (который также может доставлять пакеты конечному получателю в произвольном порядке), другие протоколы сетевого уровня, работающие поверх протокола РРР, обязаны доставлять пакеты с сохранением порядка их следования. Многоточечные линии. Протокол РРР должен работать только на линиях с одним передатчиком и одним приемником. Другие протоколы (например, HDLC) могут поддерживать линии с несколькими приемниками (как, например, в сетях Ethernet) на одной линии связи.

Формат кадра протокола РРР.

На рисунке 13.9 показан кадр протокола РРР, формат которого близок формату HDLC–кадров.

Рис.13.9 Формат кадра протокола РРР

Ниже перечислены поля кадра протокола РРР.

Поле флага. Каждый РРР–кадр начинается и заканчивается однобайтовым полем флага, в котором содержится значение 01111110. Поле адреса. Единственное возможное значение этого поля — 11111111. Управляющее поле. Единственное возможное значение этого поля — 00000011. Поскольку поле адреса и управляющее поле могут содержать только фиксированные значения, непонятно, зачем вообще нужны эти поля. В спецификации протокола РРР утверждается (RFC 1662), что «эти поля могут быть определены позднее». Поскольку у них фиксированные значения, протокол РРР разрешает отправителю вообще не посылать адресный и управляющий байты, что позволяет экономить два байта в каждом кадре. Протокол. Поле протокола сообщает РРР–получателю, какому протоколу более высокого уровня принадлежат инкапсулированные данные (то есть содержимое информационного поля РРР–кадра). Получив РРР–кадр, РРР–приемник проверяет корректность кадра, после чего передает содержащиеся в информационном поле данные соответствующему протоколу. В документах RFC 1700 и RFC 3232 определены 16–разрядные коды, используемые протоколом РРР. Нас будет интересовать протокол IP (то есть ситуация, когда инкапсулированные в РРР–кадре данные представляют собой IP–дейтаграмму), которому соответствует шестнадцатеричное значение 21 в этом поле. Кроме того, с протоколом РРР могут использоваться такие сетевые протоколы, как AppleTalk (29), DECnet (27), протокол управления каналом РРР (С021) и протокол IPCP (8021). Протокол IPCP (IP Control Protocol — протокол управления протоколом IP) вызывается протоколом РРР при первой активизации линии для конфигурирования соединения IP–уровня между двумя поддерживающими протокол IP устройствами. Информационное поле. Это поле содержит инкапсулированный пакет (данные), посылаемый протоколом более высокого уровня (например, IP) по РРР–линии. По умолчанию максимальная длина информационного поля составляет 1500 байт, хотя, как будет сказано ниже, эта величина может быть изменена во время первого конфигурирования линии. Контрольная сумма. Поле контрольной суммы используется для обнаружения ошибок в передаваемом кадре. В качестве контрольной суммы используется либо 2–байтовый, либо 4–байтовый циклический избыточный код (CRC) стандарта HDLC.

Прежде чем завершить наше обсуждение формата кадра протокола РРР, рассмотрим проблему поля флага, призванного обозначать начало и конец кадра. Что произойдет, если последовательность битов в этом поле встретится где–либо еще в пакете? Например, что случится, если стандартное для поля флага значение 01111110 встретится в информационном поле? Может ли получатель по ошибке принять этот байт за конец кадра?

Один из способов решения проблемы заключается в том, чтобы запретить протоколам более высокого уровня передавать данные, содержащие данную последовательность битов. Однако такой подход противоречит требованию прозрачности протокола РРР. Альтернативное решение, используемое в протоколе РРР, а также во многих других протоколах, представляет собой технический прием, называемый байтовой подстановкой (byte stuffing).

Протоколом РРР определяется специальный управляющий префиксный байт 01111101. Если где–либо в кадре помимо поля флага встречается флаговая последовательность битов 01111110, протокол РРР предваряет этот байт управляющим префиксным байтом. Таким образом, вставляя управляющий байт перед байтом 01111110, протокол РРР указывает, что следующий байт 01111110 не является флагом, а представляет собой данные. Получатель, встречая байт 01111101, за которым следует 01111110, удаляет управляющий префиксный байт, восстанавливая исходные данные. Аналогично, если сам управляющий префиксный байт встречается в данных, он также предваряется управляющим префиксным байтом.

Таким образом, когда получатель встречает одиночный управляющий префиксный байт, он понимает, что следом в потоке данных идет флаговая последовательность. Пара управляющих префиксных байтов подряд означает, что подобный байт идет следом в потоке данных. Пример байтовой подстановки показан на рисунке 13.10. В действительности протокол РРР инвертирует в предваряемом префиксом байте 5–й бит (выполняет с ним операцию XOR с шестнадцатеричным числом 20), но мы для простоты опустили эту деталь.

Рис.13.10 Байтовая подстановка

7. Протоколы управления каналом и сетью

До сих пор мы рассматривали формирование кадров из данных, передаваемых с помощью протокола РРР по двухточечному соединению. Но как инициализируется линия, когда на одном конце линии в сеть включается хост или маршрутизатор? Инициализацией, поддержкой, сообщением об ошибках и отключением РРР–линии занимается протокол LCP (Link Control Protocol — протокол управления каналом), а также семейство протоколов управления сетью протокола РРР.