WikiDer > Протокол точка-точка

Point-to-Point Protocol

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

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

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

Описание

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

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

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

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

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

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

LCP корректно инициирует и завершает соединения, позволяя хостам согласовывать параметры соединения. Это неотъемлемая часть PPP, определенная в той же стандартной спецификации. 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
IP
LCPГЛАВА PAP EAPIPCP
Инкапсуляция PPP
HDLC-подобное обрамлениеPPPoEPPPoA
RS-232POSEthernetБанкомат
SONET / SDH

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

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

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

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

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

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

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

  • Аутентификация - Одноранговые маршрутизаторы обмениваются сообщениями аутентификации. Два варианта аутентификации: Протокол аутентификации пароля (PAP) и Вызов протокола аутентификации рукопожатия (ГЛАВА). Аутентификация объясняется в следующем разделе.
  • Сжатие - Увеличивает эффективную пропускную способность для соединений PPP за счет уменьшения количества данных в кадре, которые должны проходить по каналу. Протокол распаковывает кадр в месте назначения. Видеть RFC 1962 Больше подробностей.
  • Обнаружение ошибок - Определяет неисправные состояния. Параметры «Качество» и «Магическое число» помогают обеспечить надежный канал передачи данных без петель. Поле Magic Number помогает обнаруживать ссылки, которые находятся в состоянии обратной петли. Пока опция конфигурации Magic-Number не будет успешно согласована, Magic-Number должен быть передан как ноль. Магические числа генерируются случайным образом на каждом конце соединения.
  • Multilink - Обеспечивает балансировку нагрузки нескольких интерфейсов, используемых PPP через Multilink PPP (см. Ниже).

Рамка PPP

Структура

Кадры PPP - это варианты HDLC кадры:

ИмяКоличество байтовОписание
Флаг10x7E, начало кадра PPP
Адрес10xFF, стандартный широковещательный адрес
Контроль10x03, ненумерованные данные
Протокол2PPP ID встроенных данных
Информацияпеременная (0 или более)дейтаграмма
Прокладкапеременная (0 или более)дополнительное заполнение
Последовательность проверки кадров2контрольная сумма кадра
Флаг10x7E, опускается для последовательных пакетов PPP

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

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

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

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

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

ИмяКоличество байтовОписание
Флаг1указывает начало или конец кадра
Адрес1широковещательный адрес
Контроль1байт управления
Протокол1 или 2 или 3l в информационном поле
Информацияпеременная (0 или более)дейтаграмма
Прокладкапеременная (0 или более)дополнительное заполнение
FCS2 (или 4)проверка ошибок

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

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

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

FCS вычисляется по полям Address, Control, Protocol, Information и Padding после инкапсуляции сообщения.

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

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

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

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

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

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

Multilink PPP - это пример агрегирование ссылок технологии. Cisco IOS Выпуск 11.1 и более поздние поддерживает Multilink PPP.

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

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

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

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

Туннели

Упрощенный OSI стек протоколов для примера SSH+ PPP туннель
ЗаявлениеFTPSMTPHTTP…DNS…
ТранспортTCPUDP
СетьIP
Канал передачи данныхPPP
ЗаявлениеSSH
ТранспортTCP
СетьIP
Канал передачи данныхEthernetБанкомат
ФизическийКабели, концентраторы и т. Д.

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

PPTP (Point-to-Point Tunneling Protocol) - это форма 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.

  • RFC 1332, Протокол управления интернет-протоколом PPP (IPCP)
  • RFC 1661, Стандарт 51, Протокол точка-точка (PPP)
  • RFC 1662, Стандарт 51, PPP в HDLC-подобном кадрировании
  • RFC 1962, Протокол управления сжатием PPP (CCP)
  • RFC 1963, Протокол передачи последовательных данных PPP
  • RFC 1877, Расширения протокола управления Интернет-протоколом PPP для адресов серверов имен
  • RFC 1990, Многоканальный протокол PPP (MP)
  • RFC 1994, Протокол проверки подлинности с вызовом PPP (CHAP)
  • RFC 2153, Информационные, Расширения для поставщиков PPP
  • RFC 2284, Расширяемый протокол аутентификации (EAP) PPP
  • RFC 2364, PPP через банкомат
  • RFC 2516, PPP через Ethernet
  • RFC 2615, PPP через SONET / SDH
  • RFC 2686, Расширение Multi-Class для Multi-Link PPP
  • RFC 2687, Предлагаемый стандарт, PPP в HDLC-подобном кадрировании, ориентированном в реальном времени
  • RFC 5072, IP версии 6 через PPP
  • RFC 5172, Согласование для сжатия дейтаграмм IPv6 с использованием протокола управления IPv6
  • RFC 6361, PPP Прозрачное соединение большого количества ссылок (ТРЕЛЬ) Протокол управления протоколом

Дополнительные проекты:

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

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

  1. ^ RFC 1968
  2. ^ а б Стивенс 1994, п. 26–27, сек. 2.6: «PPP: протокол точка-точка»
  3. ^ «Назначение полей протокола точка-точка (PPP)». IANA. Получено 3 сентября 2015.