stringtranslate.com

Протокол «точка-точка»

В компьютерных сетях протокол «точка-точка» ( PPP ) — это протокол связи уровня канала передачи данных (уровень 2) между двумя маршрутизаторами напрямую без какого-либо хоста или какой-либо другой сети между ними. Он может обеспечивать обнаружение петель, аутентификацию , шифрование передачи [1] и сжатие данных .

PPP используется во многих типах физических сетей, включая последовательный кабель , телефонную линию , магистраль , сотовый телефон , специализированные радиоканалы, ISDN и оптоволоконные каналы, такие как SONET . Поскольку IP-пакеты не могут передаваться по модемной линии сами по себе без какого-либо протокола канала передачи данных, который может определить, где начинается и где заканчивается передаваемый кадр, поставщики услуг Интернета (ISP) использовали PPP для коммутируемого доступа клиентов к Интернету .

Две производные PPP, протокол «точка-точка через Ethernet» (PPPoE) и протокол «точка-точка через ATM» (PPPoA), чаще всего используются интернет-провайдерами для установления LP-соединения интернет-услуг по цифровой абонентской линии (DSL) с клиентами. .

Описание

PPP очень часто используется в качестве протокола канального уровня для подключения по синхронным и асинхронным каналам , где он в значительной степени заменил старый протокол последовательного Интернет-протокола (SLIP) и стандарты телефонных компаний (такие как сбалансированный протокол доступа к каналу (LAPB) в набор протоколов X.25 ). Единственным требованием для PPP является то, чтобы предоставляемая линия была дуплексной . PPP был создан для работы с многочисленными протоколами сетевого уровня , включая Интернет-протокол (IP), TRILL , Novell's Internetwork Packet Exchange (IPX), NBF , DECnet и AppleTalk . Как и SLIP, это полноценное подключение к Интернету по телефонным линиям через модем. Он более надежен, чем SLIP, поскольку обеспечивает двойную проверку доставки интернет-пакетов в целости и сохранности. [2] Он повторно отправляет поврежденные пакеты.

PPP был разработан в некоторой степени по образцу исходных спецификаций HDLC . Люди, разработавшие PPP, включили в него множество дополнительных функций, которые до того времени можно было увидеть только в проприетарных протоколах передачи данных. PPP указан в RFC 1661.

RFC 2516 описывает протокол «точка-точка через Ethernet» (PPPoE) как метод передачи PPP через Ethernet , который иногда используется с DSL . RFC 2364 описывает протокол «точка-точка через ATM» (PPPoA) как метод передачи PPP через уровень адаптации ATM 5 ( AAL5 ), который также является распространенной альтернативой PPPoE, используемому с DSL.

PPP, PPPoE и PPPoA широко используются в линиях WAN .

PPP — это многоуровневый протокол, состоящий из трех компонентов: [2]

  1. Компонент инкапсуляции, используемый для передачи датаграмм по указанному физическому уровню .
  2. Протокол управления каналом (LCP) для установления, настройки и тестирования канала, а также согласования настроек, опций и использования функций.
  3. Один или несколько протоколов управления сетью (NCP), используемых для согласования дополнительных параметров конфигурации и возможностей сетевого уровня. Для каждого протокола более высокого уровня, поддерживаемого PPP, существует один NCP.

Автоматическая самоконфигурация

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

RFC 1994 описывает протокол аутентификации Challenge-Handshake (CHAP), который предпочтителен для установления коммутируемых соединений с интернет-провайдерами. Несмотря на то, что протокол аутентификации пароля (PAP) устарел, он все еще иногда используется.

Другим вариантом аутентификации через PPP является расширяемый протокол аутентификации (EAP), описанный в RFC 2284.

После установления соединения может быть выполнена дополнительная настройка сети ( уровень 3 ). Чаще всего используется протокол управления интернет-протоколом (IPCP), хотя когда-то были популярны протокол управления межсетевым обменом пакетами (IPXCP) и протокол управления AppleTalk (ATCP). [ нужна цитация ] Протокол управления Интернет-протоколом версии 6 (IPv6CP) будет широко использоваться в будущем, когда IPv6 заменит IPv4 в качестве доминирующего протокола уровня 3.

Несколько протоколов сетевого уровня

PPP позволяет нескольким протоколам сетевого уровня работать на одном и том же канале связи. Для каждого используемого протокола сетевого уровня предоставляется отдельный протокол управления сетью (NCP) для инкапсуляции и согласования опций для нескольких протоколов сетевого уровня. Он согласовывает информацию сетевого уровня, например сетевой адрес или параметры сжатия, после установления соединения.

Например, IP использует IPCP, а межсетевой обмен пакетами (IPX) использует протокол управления Novell IPX ( IPX/SPX ). NCP включают поля, содержащие стандартизированные коды, указывающие тип протокола сетевого уровня, который инкапсулирует соединение PPP.

Следующие NCP могут использоваться с PPP:

Обнаружение зацикленных ссылок

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

Варианты конфигурации

В предыдущем разделе было описано использование опций LCP для удовлетворения конкретных требований к подключению к глобальной сети. ГЧП может включать в себя следующие варианты LCP:

Рамка ГЧП

Состав

Кадры PPP являются вариантами кадров HDLC :

Если оба узла согласны на сжатие полей адреса и поля управления во время LCP, то эти поля опускаются. Аналогично, если оба узла согласны на сжатие поля протокола, то байт 0x00 можно опустить.

Поле Protocol указывает тип пакета полезной нагрузки: 0xC021 для LCP , 0x80xy для различных NCP, 0x0021 для IP, 0x0029 AppleTalk, 0x002B для IPX , 0x003D для Multilink, 0x003F для NetBIOS , 0x00FD для MPPC и MPPE и т. д. [3] PPP ограничен и не может содержать общие данные уровня 3 , в отличие от EtherType .

Поле информации содержит полезную нагрузку PPP; он имеет переменную длину с согласованным максимумом, называемым максимальной единицей передачи . По умолчанию максимум составляет 1500 октетов . Он может быть дополнен при передаче; если информация для определенного протокола может быть дополнена, этот протокол должен позволять отличать информацию от заполнения.

Инкапсуляция

Кадры PPP инкапсулируются в протокол нижнего уровня, который обеспечивает кадрирование и может предоставлять другие функции, такие как контрольная сумма для обнаружения ошибок передачи. PPP на последовательных каналах обычно инкапсулируется в структуру, аналогичную HDLC , описанную в IETF RFC 1662.

Поле Флага присутствует, когда используется PPP с HDLC-подобным кадрированием.

Поля «Адрес» и «Управление» всегда имеют шестнадцатеричное значение FF (для «всех станций») и шестнадцатеричное 03 (для «ненумерованной информации») и могут быть опущены при согласовании сжатия адреса и поля управления PPP LCP (ACFC). .

Поле последовательности проверки кадра (FCS) используется для определения наличия ошибки в отдельном кадре. Он содержит контрольную сумму, вычисляемую по кадру, чтобы обеспечить базовую защиту от ошибок при передаче. Это код CRC , аналогичный тому, который используется в других схемах защиты от ошибок протокола второго уровня, например, в Ethernet. Согласно RFC 1662, он может иметь размер либо 16 бит (2 байта), либо 32 бита (4 байта) (по умолчанию 16 бит — Polynomial x 16 + x 12 + x 5 + 1).

FCS рассчитывается по полям «Адрес», «Управление», «Протокол», «Информация» и «Заполнение» после инкапсуляции сообщения.

Активация линии и фазы

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

По нескольким ссылкам

Многоканальный PPP

Многоканальный PPP (также называемый MLPPP , MP , MPPP , MLP или Multilink) обеспечивает метод распределения трафика по нескольким отдельным соединениям PPP. Он определен в RFC 1990. Его можно использовать, например, для подключения домашнего компьютера к интернет-провайдеру с помощью двух традиционных модемов 56k или для подключения компании через две выделенные линии.

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

Многоканальный PPP является примером технологии агрегации каналов . Cisco IOS версии 11.1 и более поздних версий поддерживает многоканальный PPP.

Мультиклассовый ППС

При использовании PPP невозможно установить несколько одновременных отдельных соединений PPP по одному каналу.

Это невозможно и при использовании Multilink PPP. Многоканальный PPP использует смежные номера для всех фрагментов пакета, и, как следствие, невозможно приостановить отправку последовательности фрагментов одного пакета для отправки другого пакета. Это предотвращает возможность многократного запуска Multilink PPP по одним и тем же каналам.

Мультиклассовый PPP — это разновидность многоканального PPP, в котором каждый «класс» трафика использует отдельное пространство порядковых номеров и буфер повторной сборки. Мультиклассовый PPP определен в RFC 2686.

Туннели

Производные протоколы

PPTP (Протокол туннелирования «точка-точка») — это форма PPP между двумя хостами через GRE с использованием шифрования ( MPPE ) и сжатия ( MPPC ).

Как протокол уровня 2 между обоими концами туннеля.

Многие протоколы могут использоваться для туннелирования данных по IP-сетям. Некоторые из них, такие как SSL , SSH или L2TP , создают виртуальные сетевые интерфейсы и создают впечатление прямых физических соединений между конечными точками туннеля. Например, на хосте Linux эти интерфейсы будут называться tun0 или ppp0 .

Поскольку в туннеле имеется только две конечные точки, туннель представляет собой соединение «точка-точка», и PPP является естественным выбором в качестве протокола канального уровня между виртуальными сетевыми интерфейсами. PPP может назначать этим виртуальным интерфейсам IP-адреса, и эти IP-адреса можно использовать, например, для маршрутизации между сетями по обе стороны туннеля.

IPsec в режиме туннелирования не создает виртуальные физические интерфейсы в конце туннеля, поскольку туннель обрабатывается непосредственно стеком TCP/IP. Для предоставления этих интерфейсов можно использовать L2TP , этот метод называется L2TP/IPsec. В этом случае PPP также предоставляет IP-адреса концам туннеля.

стандарты IETF

PPP определен в RFC 1661 (Протокол «точка-точка», июль 1994 г.). RFC 1547 (Требования к стандартному протоколу двухточечной связи Интернета, декабрь 1993 г.) предоставляет историческую информацию о необходимости PPP и его развитии. Был написан ряд связанных RFC, чтобы определить, как различные протоколы управления сетью, включая TCP/IP , DECnet , AppleTalk , IPX , работают с PPP; их можно найти на веб-сайте Datatracker IETF. [4]

Смотрите также

Рекомендации

  1. ^ RFC  1968
  2. ^ ab Stevens 1994, стр. 26–27, раздел 2.6: «PPP: протокол двухточечной связи»
  3. ^ «Назначения полей протокола двухточечной связи (PPP)» . ИАНА . Проверено 3 сентября 2015 г.
  4. ^ «Отслеживание данных IETF» . Проверено 26 августа 2023 г.