Network Working Group K. Hamzeh Request for Comments: 2637 Ascend Communications Category: Informational G. Pall Microsoft Corporation W. Verthein 3Com J. Taarud Copper Mountain Networks W. Little ECI Telematics G. Zorn Microsoft Corporation July 1999
Туннельный протокол PPTP
Point-to-Point Tunneling Protocol (PPTP)
Статус документа
Этот документ содержит информацию для сообщества Internet и не задает каких-либо стандартов Internet. Документ может распространяться свободно.
Авторские права
Copyright (C) The Internet Society (1999). All Rights Reserved.
Замечание IESG
Протокол PPTP был разработан консорциумом производителей. Документация по протоколу PPTP представляется в качестве информации для сообщества Internet. Рабочая группа PPP WG в настоящее время готовит проект стандарта протокола L2TP для туннелирования PPP через сети с коммутацией пакетов.
Аннотация
В этом документе приведена спецификация протокола, позволяющего туннелировать трафик PPP1 через сети IP. PPTP не вносит каких-либо изменений в протокол PPP, а вместо этого описывает новый транспорт для доставки PPP. Определена архитектура «клиент-сервер» для развязки с функциями, существующими в современных серверах доступа в сеть (NAS2) и поддерживающими VPN3. Для работы под управлением операционных систем общего назначения предусматривается сервер PNS4, а клиенты (PAC5) работают на серверах доступа по коммутируемым линиям. PPTP задает протокол управления вызовами и протокол управления, которые позволяют серверу контролировать доступ по коммутируемым линиям из сетей PSTN и ISDN или инициировать исходящие коммутируемые соединения. PPTP использует расширенный механизм GRE6 для предоставления услуг по доставке дейтаграмм с контролем потоков и перегрузок для пакетов PPP.
Спецификация требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [12].
Слова «отбрасывание без уведомления» (silently discard) в контексте поведения реализации при получении пакета интерпретируются следующим образом — реализация отбрасывает дейтаграмму без последующей обработки и уведомления отправителя о факте отбрасывания. Реализациям следует обеспечивать возможность внесения в системный журнал сообщений об ошибках, включающих содержимое отбрасываемых дейтаграмм, в также следует поддерживать счетчик случаев отбрасывания.
Оглавление
Исключено в версии HTML.
1. Введение
PPTP позволяет разделить функции имеющихся серверов доступа (NAS7) с использованием архитектуры «клиент-сервер». Традиционно в устройствах NAS реализуются перечисленные ниже функции:
-
Естественное взаимодействие на физическом уровне с сетями PSTN и ISDN, а также управление внешними модемами и терминальными адаптерами.
NAS может напрямую взаимодействовать а аналоговым или цифровым устройством телефонной сети или подключаться к ней через внешние модемы и терминальные адаптеры. Управление коммутируемыми соединениями обеспечивается средствами управления модемами или протоколами управления вызовами DSS1 ISDN.
Устройство NAS вместе с модемами и терминальными адаптерами может выполнять адаптацию скорости соединения, преобразование между аналоговыми и цифровыми форматами, преобразование между синхронными и асинхронными каналами, а также другие преобразования потоков данных.
-
Участие в протоколе аутентификации PPP [3,9,10].
-
Агрегирование каналов и управление канальными группами PPP Multilink Protocol.
-
Логическое завершение различных протоколов управления сетью PPP NCP10.
-
Мультипротокольная маршрутизация и мосты между интерфейсами NAS.
PPTP распределяет перечисленные функции между PAC и PNS. Устройства PAC отвечают за функции 1, 2 и, возможно, 3. Устройства PNS могут отвечать за функцию 3 и отвечают за функции 4, 5 и 6. Протокол обмена PPP PDU11 между устройствами PAC и PNS, а также управления вызовами обеспечивается PPTP.
Разделение функций NAS обеспечивает ряд преимуществ.
Гибкое управление адресами IP. Пользователи коммутируемых линий могут применять один адрес IP для подключения через разные PAC, если эти устройства обслуживаются общим PNS. Если в сети предприятия используются незарегистрированные адреса, PNS сети предприятия выделяет адреса из приватной сети.
Поддержка отличных от IP протоколов для доступа в сети. Это позволяет организовать соединения Appletalk или IPX с туннелированием через сети, поддерживающие только IP. Устройство PAC должно поддерживать такие протоколы.
Решение проблемы multilink hunt-group splitting. Протокол Multilink PPP, обычно используемый для объединения каналов ISDN B, требует, чтобы все каналы группы приходили на одно устройство NAS. Поскольку группа каналов PPP может обслуживаться одним устройством PNS, включенные в эту группу каналы могут приходить на разные устройства PAC.
1.1. Цели и допущения
Для реализации протокола PPTP нужны лишь устройства PAC и PNS. Никакие другие системы не требуются для работы PPTP. Коммутируемые линии могут подключаться к PAC, ничего не зная о PPTP. Стандартные клиентские программы PPP продолжают работать по туннелируемым каналам PPP.
PPTP можно также применять для туннелирования сессий PPP через сети IP. В этом случае туннель PPTP и сессия PPP организуются между одной парой машин и вызывающая сторона действует, как PNS.
Предполагается возможность мгогосвязных взаимодействий между устройствами PAC и PNS. Концентратор PAC может обслуживать множество серверов PNS. Например, Internet-провайдеры могут поддерживать услуги PPTP для множества клиентов частной сети и создавать для них соединения VPN. Каждая частная сеть при этом может использовать один или множество серверов PNS. Один сервер PNS можно связать с множеством PAC для концентрации трафика из большого числа географически распределенных сайтов.
Протокол PPTP использует расширенную версию GRE для переноса пользовательских пакетов PPP. Это обеспечивает возможность контроля насыщения и управления потоком данных на нижних уровнях туннелей, применяемых для переноса пользовательских данных между устройствами PAC и PNS. Этот механизм обеспечивает эффективное использование доступной для туннелей полосы и позволяет предотвратить ненужные повторы передачи и переполнение буферов. PPTP не задает конкретных алгоритмов контроля для нижних уровней, но определяет параметры, обмен которыми требуется для обеспечения работы таких алгоритмов. Возможные алгоритмы рассмотрены в разделе 4.
1.2. Терминология
Analog Channel — аналоговый канал
Коммуникационный путь с коммутацией каналов, предназначенный для передачи звука в полосе частот 3,3 Кгц в каждом направлении.
Digital Channel — цифровой канал
Коммуникационный путь с коммутацией каналов, предназначенный для передачи цифровой информации в каждом направлении.
Call – вызов
Соединение или попытка соединения между двумя оконечными точками телефонной сети PSTN или ISDN (например, для соединения между двумя модемами).
Control Connection — управляющее соединение
Управляющее соединение организуется для каждой пары PAC – PNS и работает по протоколу TCP [4]. Соединение служит для управления туннелем и связанными с ним сессиями.
Dial User — пользователь коммутируемого соединения
Оконечная система или маршрутизатор, подключаемые по запросу к телефонной сети PSTN или ISDN. Может быть как инициатором, так и вызываемой стороной.
Network Access Server (NAS) — сервер доступа в сеть
Устройство, обеспечиваемое временный (по запросу) доступ в сеть для пользователей. Доступ осуществляется в режиме «точка-точка» с использованием телефонных линий PSTN или ISDN.
PPTP Access Concentrator (PAC) — концентратор доступа
Устройство, подключенное к одной или множеству линий PSTN или ISDN, поддерживающее протокол PPP и обслуживающее протокол PPTP. От устройств PAC поддержка стека TCP/IP требуется только для передачи трафика одному или множеству устройств PNS. Концентратор может также туннелировать протоколы, не относящиеся к IP.
PPTP Network Server (PNS) — сетевой сервер PPTP
Предполагается, что PNS будут разворачиваться на компьютерных (серверных) платформах общего назначения. PNS реализует серверную часть протокола PPTP. Поскольку PPTP работает на основе стека TCP/IP и не зависит от интерфейсного оборудования, PNS может работать с любыми комбинациями интерфейсов IP, включая устройства LAN и WAN.
Session – сессия
Протокол PPTP основан на соединениях. Устройства PNS и PAC поддерживают состояние для каждого пользователя, подключенного к PAC. Сессия открывается при попытке организации сквозного соединения PPP между пользователем и PNS по коммутируемой линии. Относящиеся к сессии дейтаграммы передаются через туннель между PAC и PNS.
Tunnel – туннель
Туннель определяется парой PNS – PAC. Туннельный протокол определяется модифицированной версией GRE [1, 2]. Туннель служит для передачи дейтаграмм PPP между устройствами PAC и PNS. В одном туннеле может мультиплексироваться множество сессий. Управляющее соединение на основе протокола TCP служит для организации, поддержки и завершения сессий и самого туннеля.
1.3. Обзор протокола
Протокол PPTP включает две работающих параллельно компоненты – 1) управляющее соединение между каждой парой PAC — PNS, работающее по протоколу TCP и 2) туннель IP между той же парой устройств PAC — PNS, служащий для транспортировки инкапсулированных с помощью GRE пакетов PPP в пользовательских сессиях между парой устройств.
1.3.1. Управляющее соединение
Для создания туннеля PPP между PAC и PNS, требуется сначала организовать между этими устройствами управляющее соединение. Это соединение представляет собой обычную сессию TCP, через которую передается информация управления вызовами и соединением PPTP. Сеанс управления логически связан с сессиями, организуемыми через туннель PPTP, но отделен от этих сессий. Для каждой пары PAC – PNS имеется управляющее соединение и туннель. Управляющее соединение отвечает за организацию, поддержку и завершение сессий, организуемых через туннель. Оно обеспечивает средства, с помощью которых PNS уведомляется о входящих вызовах на PAC, а также способов уведомления PAC о необходимости организации исходящего вызова.
Инициатором организации управляющего соединения может выступать PNS или PAC. После организации требуемого для работы соединения TCP устройства PNS и PAC организуют между собой управляющее соединение, используя сообщения Start-Control-Connection-Request и Start-Control-Connection-Reply. Эти сообщения служат также для обмена информацией о базовых возможностях PAC и PNS. После организации управляющего соединения PAC или PNS может инициировать сессии, запрашивая исходящие соединения или отвечая на входящие. Через управляющее соединение может выполняться обмен информацией о рабочих параметрах отдельных пользовательских сессий с помощью сообщений Set-Link-Info. Пользовательские сессии могут освобождаться (разрываться) устройством PAC или PNS с помощью сообщений управления соединениями (Control Connection).
Для поддержки самого управляющего соединения используются сообщения keep-alive. Это обеспечивает своевременное обнаружение разрывов соединения между PNS и PAC. О других отказах информация передается через управляющее соединение в сообщениях Wan-Error-Notify.
Предполагает, что в будущем через управляющие соединения станут передаваться также связанные с поддержкой соединения (например, позволяющие PNS запросить статус данного PAC). Пока таких сообщений не определено.
1.3.2. Протокол туннелирования
PPTP требует организации туннеля для каждой взаимодействующей пары PNS – PAC. Этот туннель служит для передачи пакетов PPP всех пользовательских сессий, проходящих через данную пару PNS – PAC. Ключ в заголовке GRE указывает к какой из сессий относится конкретный пакет PPP.
Такой способ обеспечивает мультиплексирование и демультиплексирование пакетов PPP через один туннель между парой устройств PNS – PAC. Используемое в качестве ключа значение задается процедурой организации вызова через управляющее соединение.
Заголовок GRE содержит также информацию о подтверждениях и порядковых номерах, которая позволяет организовать некий контроль насыщения и детектирование ошибок на уровне туннеля. Управляющее соединение используется для задания скорости и параметров буферизации, которые будут служить для управления потоком пакетов PPP отдельной сессии в данном туннеле. PPTP не задает конкретных алгоритмов контроля насыщения и управления потоком данных. Предлагаются алгоритмы определения адаптивных тайм-аутов для восстановления в случаях потери данных или подтверждений в туннеле (см. параграф 4.4).
1.4. Формат сообщений и расширяемость протокола
PPTP определяет набор сообщений, передаваемых через управляющее соединение TCP между устройствами PNS и PAC. Сессия TCP для управляющего соединения организуется инициатором соединения TCP через порт 1723 [6]. Порт-источник выбирается отправителем из числа свободных.
Каждое управляющее соединение PPTP Control Connection начинается с 8-октетного заголовка, включающего общий размер сообщения, индикатор типа сообщения PPTP и Magic Cookie.
Поле PPTP Message Type может указывать два типа сообщений Control Connection:
1 – Control Message (управление);
2 – Management Message (поддержка).
Сообщения типа Management в настоящее время не определены.
Поле Magic Cookie всегда имеет значение 0x1A2B3C4D. Основным назначением этого поля является обеспечение получателю возможности проверить корректность синхронизации потока данных TCP. Не следует применять средства ресинхронизации потока данных TCP, если отправитель передал сообщение с некорректным форматом. При потере синхронизации сессия TCP для управляющего соединения должна закрываться незамедлительно.
Для ясности все шаблоны сообщений Control Connection в следующем разделе указаны с полными заголовками PPTP Control Connection. Числовые значения с префиксом 0x обозначают шестнадцатеричные числа.
Определенные в настоящее время управляющие сообщения перечислены в таблице.
|
Управляющее сообщение |
Код |
|
Поддержка управляющего соединения |
|
|
Start-Control-Connection-Request |
1 |
|
Start-Control-Connection-Reply |
2 |
|
Stop-Control-Connection-Request |
3 |
|
Stop-Control-Connection-Reply |
4 |
|
Echo-Request |
5 |
|
Echo-Reply |
6 |
|
Управление вызовами |
|
|
Outgoing-Call-Request |
7 |
|
Outgoing-Call-Reply |
8 |
|
Incoming-Call-Request |
9 |
|
Incoming-Call-Reply |
10 |
|
Incoming-Call-Connected |
11 |
|
Call-Clear-Request |
12 |
|
Call-Disconnect-Notify |
13 |
|
Сообщения об ошибках |
|
|
WAN-Error-Notify |
14 |
|
Управление сессией PPP |
|
|
Set-Link-Info |
15 |
Сообщения Start-Control-Connection-Request и Start-Control-Connection-Reply определяют используемую версию протокола Control Connection. Поле номера версии, передаваемое в таких сообщениях содержит номер версии в старшем октете и номер ревизии в младшем. Обработка номеров версий описана в разделе 2. В текущей версии протокола поле имеет значение 0x0100 — версия 1, ревизия 0.
Использование заголовков в стиле GRE для инкапсуляции пользовательских пакетов PPP описано в параграфе 4.1.
MTU для пользовательских пакетов, инкапсулируемых в GRE, составляет 1532 октета без учета заголовков IP и GRE.
2. Спецификация протокола управления соединениями
Сообщения Control Connection служат для организации и разрыва пользовательских сессий. Первый набор сообщений Control Connection используется для организации управляющего соединения. Это соединение инициируется устройством PNS или PAC после того, как между ними будет создано транспортное соединение TCP. Процедуры и конфигурационные параметры организуемого соединения TCP не задаются данным протоколом.
Последующие сообщения Control Connection передаются, как пользовательские данные через организованное соединение TCP между данной парой устройств PNS – PAC. Следует обращать внимание на то, чтобы все 2-х (word) и 4-октетные (longword) значения выравнивались по соответствующим границам. Все данные передаются с использованием сетевого порядка (сначала старший октет). Все резервные поля должны при передаче устанавливаться в 0 для обеспечения совместимости с будущими версиями протокола.
2.1. Start-Control-Connection-Request
Start-Control-Connection-Request представляет собой управляющее сообщение PPTP, используемое для организации управляющего соединения между PNS и PAC. Для каждой пары PNS – PAC требуется выделенное управляющее соединение, которое должно быть организовано до того, как начнется обмен другими сообщениями PPTP. Организации управляющего соединения может быть инициирована PNS или PAC. Процедура обработки конфликтов между PNS и PAC при обработке сообщений Start-Control-Connection-Requests описана в параграфе 3.1.3.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bearer Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Channels | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Host Name (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Vendor String (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D. Эта константа используется для проверки корректности принимаемых сообщений (см. параграф 1.4).
Control Message Type
1 для Start-Control-Connection-Request.
Reserved0
Должно иметь значение 0.
Protocol Version
Версия протокола PPTP, которую хочет применять отправитель.
Reserved1
Должно иметь значение 0.
Framing Capabilities
Набор битов, показывающий возможности кадрирования, которые обеспечивает отправитель данного сообщения. В настоящее время поддерживается два варианта:
1 — асинхронное кадрирование;
2 — синхронное кадрирование.
Bearer Capabilities
Набор битов, показывающий возможности, которые может обеспечить отправитель сообщения. В настоящее время определены два варианта:
1 — поддержка аналогового доступа;
2 — поддержка цифрового доступа.
Maximum Channels
Общее число сессий PPP, которые может поддерживать данное устройство PAC. В сообщениях Start-Control-Connection-Request от PNS для этого поля следует указывать 0. Такие значения должны игнорироваться PAC.
Firmware Revision
Это поле указывает номер версии ПО PAC для сообщений от устройства PAC или версии драйвера PNS PPTP для сообщений от устройства PNS.
Host Name
64-октетное поле, содержащее доменное имя передающего сообщение устройства PAC или PNS. Для имен размером менее 64 октетов неиспользуемые октеты следует заполнять нулями.
Vendor Name
64-октетное поле, содержащее строку описания типа устройства PAC (для сообщений от PAC) или типа программ, используемых PNS (для сообщений от PNS). Для строк размером менее 64 октетов неиспользуемые октеты следует заполнять нулями.
2.2. Start-Control-Connection-Reply
Start-Control-Connection-Reply представляет собой управляющее сообщение PPTP, которое передается в ответ на Start-Control-Connection-Request. Это сообщение включает код результата попытки организации соединения.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | Result Code | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bearer Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Channels | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Host Name (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Vendor String (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
2 для Start-Control-Connection-Reply.
Reserved0
Должно иметь значение 0.
Protocol Version
Версия протокола PPTP, которую хочет применять отправитель.
Result Code
Показывает результат попытки организации командного канала:
1 — успешная организация соединения;
2 — ошибка общего типа, значение Error Code более точно указывает проблему;
3 — командный канал уже организован;
4 — запрашивающая сторона не уполномочена создавать командный канал;
5 — запрошенная версия протокола не поддерживается.
Error Code
Это поле имеет значение 0, если не возникла ошибка общего типа (Result Code = 2). В последнем случае данное поле содержит один из кодов ошибок общего типа, описанных в параграфе 2.1612.
Framing Capabilities
Набор битов, показывающий возможности кадрирования, которые обеспечивает отправитель данного сообщения. В настоящее время поддерживается два варианта:
1 — асинхронное кадрирование;
2 — синхронное кадрирование.
Bearer Capabilities
Набор битов, показывающий возможности, которые может обеспечить отправитель сообщения. В настоящее время определены два варианта:
1 — поддержка аналогового доступа;
2 — поддержка цифрового доступа.
Maximum Channels
Общее число сессий PPP, которые может поддерживать данное устройство PAC. В сообщениях Start-Control-Connection-Reply от PNS для этого поля следует указывать 0. Такие значения должны игнорироваться PAC. Устройствам PNS недопустимо использовать значение этого поля для попыток определения число сессий PPP, которое устройство PAC еще позволит добавить.
Firmware Revision
Это поле указывает номер версии ПО PAC для сообщений от устройства PAC или версии драйвера PNS PPTP для сообщений от устройства PNS.
Host Name
64-октетное поле, содержащее доменное имя передающего сообщение устройства PAC или PNS. Для имен размером менее 64 октетов неиспользуемые октеты следует заполнять нулями.
Vendor Name
64-октетное поле, содержащее строку описания типа устройства PAC (для сообщений от PAC) или типа программ, используемых PNS (для сообщений от PNS). Для строк размером менее 64 октетов неиспользуемые октеты следует заполнять нулями.
2.3. Stop-Control-Connection-Request
Stop-Control-Connection-Request представляет собой управляющее сообщение PPTP, передаваемое одним из устройств пары PAC – PNS своему партнеру для информирования о потребности в закрытии управляющего соединения. При разрыве управляющего соединения неявно разрываются и все связанные с ним сессии пользователей. Причина разрыва соединение указывается в поле Reason.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Reserved1 | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
3 для Stop-Control-Connection-Request.
Reserved0
Должно иметь значение 0.
Reason
Указывает причину разрыва управляющего соединения:
1 (None) — обычный запрос на разрыв соединения;
2 (Stop-Protocol) — не поддерживается используемая партнером версия протокола;
3 (Stop-Local-Shutdown) — запрашивающая сторона будет выключена (shut down).
Reserved1, Reserved2
Должны иметь значение 0.
2.4. Stop-Control-Connection-Reply
Stop-Control-Connection-Reply представляет собой управляющее сообщение PPTP, передаваемое устройством пары PAC – PNS своему партнеру при получении от того сообщения Stop-Control-Connection-Request.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Error Code | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
4 для Stop-Control-Connection-Reply.
Reserved0
Должно иметь значение 0.
Result Code
Указывает результат попытки закрыть соединение:
1 (OK) — управляющее соединение закрыто;
2 (General Error) — соединение не удалось закрыть, причина указана в Error Code
Error Code
Это поле имеет значение 0, если не возникла ошибка общего типа (Result Code = 2). В последнем случае данное поле содержит один из кодов ошибок общего типа, описанных в параграфе 2.1613.
Reserved1
Должно иметь значение 0.
2.5. Echo-Request
Сообщения Echo-Request может передавать любой из участников пары PAC – PNS. Эти сообщения служат для поддержки существования управляющего соединения (keep-alive). Принимающая сторона отвечает сообщением Echo-Reply на каждое полученное сообщение Echo-Request. Как отмечено в параграфе 3.1.4, если отправитель эхо-запроса не получает в ответ сообщения Echo-Reply, он будет в конечном итоге разрывать управляющее соединение.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
5 для Echo-Request.
Reserved0
Должно иметь значение 0.
Identifier
Значение устанавливается отправителем Echo-Request для того, чтобы сопоставить отклики с запросами.
2.6. Echo-Reply
Сообщения Echo-Reply может передавать любой из участников пары PAC – PNS в ответ на Echo-Request от партнера.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Error Code | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
6 для Echo-Reply.
Reserved0
Должно иметь значение 0.
Identifier
Значение этого поля копируется из соответствующего сообщения Echo-Request.
Result Code
Показывает результат обработки запроса Echo-Request:
1 (OK) — сообщение Echo-Reply корректно;
2 (General Error) — сообщение Echo-Request не воспринято по причине, указанной полем Error Code
Error Code
Это поле имеет значение 0, если не возникла ошибка общего типа (Result Code = 2). В последнем случае данное поле содержит один из кодов ошибок общего типа, описанных в параграфе 2.1614.
Reserved1
Должно иметь значение 0.
2.7. Outgoing-Call-Request
Сообщения Outgoing-Call-Request передаются устройством PNS своему партнеру PAC для обозначения потребности в организации исходящего с PAC вызова. Этот запрос предоставляет устройству PAC информацию, требуемую для исходящего вызова, а также сведения, используемые PAC для управления данными, которые будут передаваться PNS в результате организации сессии.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | Call Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bearer Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Recv. Window Size | Packet Processing Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Phone Number Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Phone Number (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subaddress (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
7 для Outgoing-Call-Request.
Reserved0
Должно иметь значение 0.
Call ID
Уникальный идентификатор, выделенный устройством PNS для данной сессии и применяемый для мультиплексирования и демультиплексирования данных, передаваемых через общий туннель между PNS и PAC.
Call Serial Number
Идентификатор, выделенный устройством PNS для данной сессии с целью ее обозначения в системных журналах устройства. В отличие от Call ID, оба устройства PNS и PAC связывают с данной сессией одно значение Call Serial Number. Следует обеспечивать уникальность для комбинации адреса IP и порядкового номера вызова.
Minimum BPS
Минимальная приемлемая скорость (в бит/с) в линии для данной сессии.
Maximum BPS
Максимальная приемлемая скорость (в бит/с) в линии для данной сессии.
Bearer Type
Значение, указывающее возможности, требуемые для исходящего вызова:
1 — вызов может быть организован по аналоговому каналу;
2 — вызов может быть организован по цифровому каналу;
3 — вызов может быть организован по аналоговому или цифровому каналу.
Framing Type
Значение, указывающее тип кадрирования PPP для использования с данным исходящим вызовом:
1 — асинхронное кадрирование;
2 — синхронное кадрирование;
3 — асинхронное или синхронное кадрирование.
Packet Recv. Window Size
Число принятых пакетов данных, которые PNS будет буферизовать для данной сессии.
Packet Processing Delay
Мера задержки, которая может возникать при передаче данных от PAC к PNS, в десятых долях секунды (1/10 с). Для PNS это значение следует делать очень малым. Рекомендации по выбору значения даны в параграфе 4.4.
Phone Number Length
Актуальное число цифр, которые могут указываться в поле телефонного номера (Phone Number).
Reserved1
Должно иметь значение 0.
Phone Number
Телефонный номер, который будет применяться для исходящего вызова. Для ISDN и аналоговых линий это поле является строкой ASCII. Если размер строки номера меньше 64 октетов, свободные октеты заполняются нулями.
Subaddress
64-октетное поле, служащее для передачи дополнительной информации. Если размер дополнительной информации меньше 64 октетов, свободные октеты заполняются нулями.
2.8. Outgoing-Call-Reply
Сообщения Outgoing-Call-Reply устройство PAC передает PNS в ответ на Outgoing-Call-Request. Этот отклик показывает результат попытки исходящего вызова и предоставляет PNS дополнительные данные о параметрах вызова. Полученная информация позволяет PNS регулировать в этой сессии передачу данных PAC.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | Peer's Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Error Code | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connect Speed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Recv. Window Size | Packet Processing Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Physical Channel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
8 для Outgoing-Call-Reply.
Reserved0
Должно иметь значение 0.
Call ID
Уникальный идентификатор, выделенный устройством PAC для данной сессии и применяемый для мультиплексирования и демультиплексирования данных, передаваемых через общий туннель между PNS и PAC.
Peer’s Call ID
В это поле копируется значение Call ID из соответствующего запроса Outgoing-Call-Request. Поле используется PNS для сопоставления Outgoing-Call-Reply с переданным ранее Outgoing-Call-Request, а также включается в заголовок GRE для мультиплексирования и демультиплексирования.
Result Code
Это значение показывает результат обработки Outgoing-Call-Request:
1 (Connected) — вызов выполнен без ошибок;
2 (General Error) — исходящий вызов не удался, код ошибки указан в Error Code;
3 (No Carrier) — отсутствие сигнала несущей в линии;
4 (Busy) — линия занята;
5 (No Dial Tone) — отсутствие сигнала вызова в линии;
6 (Time-out) — вызов не удалось организовать в течение времени, отведенного устройством PAC;
7 (Do Not Accept) — исходящий вызов запрещен административно.
Error Code
Это поле имеет значение 0, если не возникла ошибка общего типа (Result Code = 2). В последнем случае данное поле содержит один из кодов ошибок общего типа, описанных в параграфе 2.1615.
Cause Code
Это поле содержит дополнительную информацию о причине отказа. Значение поля может меняться в зависимости от типа вызова. Для вызовов ISDN используются коды причин Q.931.
Connect Speed
Установленная скорость соединения (бит/с).
Packet Recv. Window Size
Число принятых пакетов данных, которые PAC будет буферизовать для этой сессии.
Packet Processing Delay
Мера задержки, которая может возникать при передаче данных от PNS к PAC, в десятых долях секунды (1/10 с). Для PAC это значение связано с размером буфера, используемого для передаваемых клиенту пакетов и скорости в соединяющей с клиентом линии. Следует устанавливать максимальное значение задержки, которая обычно возникает между получением пакета устройством PAC и его отправкой клиенту. Рекомендации по выбору значения даны в параграфе 4.4.
Physical Channel ID
Это поле устанавливается устройством PAC и выбор значений зависит от производителя оборудования. Значение применяется лишь для протоколирования работы.
2.9. Incoming-Call-Request
Сообщения Incoming-Call-Request передаются устройством PAC устройству PNS для индикации входящего вызова, принятого PAC. Запрос передает устройству PNS параметры, связанные с этим входящим вызовом.
Это сообщение является первым в трехэтапном согласовании (three-way handshake), используемом протоколом PPTP для входящих вызовов. PAC может отложить восприятие вызова до момента получения Incoming-Call-Reply от устройства PNS, показывающего согласие на организацию соединения. Этот механизм позволяет PNS получить до организации соединения информацию, которая позволяет принять решение о восприятии вызова или отказе от него.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | Call Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Bearer Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Physical Channel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dialed Number Length | Dialing Number Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Dialed Number (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Dialing Number (64 октета) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subaddress (64 октета) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
9 для Incoming-Call-Request.
Reserved0
Должно иметь значение 0.
Call ID
Уникальный идентификатор, выделенный устройством PAC для данной сессии и применяемый для мультиплексирования и демультиплексирования данных, передаваемых через общий туннель между PNS и PAC.
Call Serial Number
Идентификатор, выбранный устройством PAC для этой сессии с целью ее обозначения при записи информации в системный журнал. В отличие от Call ID, оба устройства PNS и PAC связывают с данной сессией одно значение Call Serial Number. Следует обеспечивать уникальность для комбинации адреса IP и порядкового номера вызова.
Bearer Type
Значение, указывающее тип входящего вызова:
1 — вызов по аналоговому каналу;
2 — вызов по цифровому каналу.
Physical Channel ID
Это поле устанавливается PAC для нумерации физического канала, принявшего вызов.
Dialed Number Length
Актуальное число цифр, которые могут указываться в поле телефонного номера (Dialed Number.
Dialing Number Length
Актуальное число цифр, которые могут указываться в поле телефонного номера (Dialing Number).
Dialed Number
Номер, набранный вызывающей стороной. Для аналоговых линий и ISDN это поле представляет собой строку ASCII. Если размер строки Dialed Number менее 64 октетов, неиспользуемые октеты заполняются нулями.
Dialing Number
Номер, с которого был организован входящий вызов. Для аналоговых линий и ISDN это поле представляет собой строку ASCII. Если размер строки Dialing Number менее 64 октетов, неиспользуемые октеты заполняются нулями.
Subaddress
64-октетное поле, служащее для передачи дополнительной информации. Если размер дополнительной информации меньше 64 октетов, свободные октеты заполняются нулями.
2.10. Incoming-Call-Reply
Сообщение Incoming-Call-Reply передается устройством PNS концентратору PAC в ответ на полученное от того сообщение Incoming-Call-Request. Отклик показывает результат попытки организации соединения и содержит дополнительную информацию, позволяющую устройству PAC управлять для этой сессии передачей данных в PNS.
Это сообщение является вторым в трехэтапном согласовании при обработке входящих вызовов PPTP. Оно показывает устройству PAC следует ли принять или отвергнуть входящий вызов.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | Peer's Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Error Code | Packet Recv. Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Transmit Delay | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
10 для Incoming-Call-Reply.
Reserved0
Должно иметь значение 0.
Call ID
Уникальный идентификатор, выделенный устройством PNS для данной сессии и применяемый для мультиплексирования и демультиплексирования данных, передаваемых через общий туннель между PNS и PAC.
Peer’s Call ID
В это поле копируется значение Call ID из соответствующего запроса Incoming-Call-Request. Поле используется PAC для сопоставления Incoming-Call-Reply с переданным ранее Incoming-Call-Request, а также включается в заголовок GRE для мультиплексирования и демультиплексирования.
Result Code
Значение, показывающее результат обработки Incoming-Call-Request:
1 (Connect) — устройству PAC следует принять входящий вызов;
2 (General Error) — соединение для входящего вызова не следует организовывать по причине, указанной Error Code;
3 (Do Not Accept) – PAC не следует принимать входящий вызов («положить трубку» или передать сигнал «занято»).
Error Code
Это поле имеет значение 0, если не возникла ошибка общего типа (Result Code = 2). В последнем случае данное поле содержит один из кодов ошибок общего типа, описанных в параграфе 2.1616.
Packet Recv. Window Size
Число принимаемых пакетов, которые PAC будет буферизовать для данной сессии.
Packet Transmit Delay
Мера задержки, которая может возникать при передаче данных от PAC к PNS, в десятых долях секунды (1/10 с).
Reserved1
Должно иметь значение 0.
2.11. Incoming-Call-Connected
Сообщение Incoming-Call-Connected концентратор PAC передает серверу PNS в ответ на полученное от того сообщение Incoming-Call-Reply. Данное сообщение обеспечивает PNS информацию о конкретных параметрах вызова, а также сведения, позволяющие серверу PNS регулировать передачу данных концентратору PAC.
Это сообщение является третьим в трехэтапном согласовании, используемом PPTP для входящих вызовов. Оно обеспечивает механизм предоставления серверу PNS дополнительной информации, которую в общем случае невозможно получить в момент передачи концентратором PAC сообщения Incoming-Call-Request.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer's Call ID | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connect Speed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Recv. Window Size | Packet Transmit Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
11 для Incoming-Call-Connected.
Reserved0
Должно иметь значение 0.
Peer’s Call ID
В это поле копируется значение Call ID из соответствующего запроса Incoming-Call-Reply. Поле используется PNS для сопоставления Incoming-Call-Connected с переданным ранее Incoming-Call-Reply.
Connect Speed
Реально используемая для соединения скорость (бит/с)
Packet Recv. Window Size
Число принимаемых пакетов, которые PAC будет буферизовать для данной сессии.
Packet Transmit Delay
Мера задержки, которая может возникать при передаче данных от PAC к PNS, в десятых долях секунды (1/10 с).
Framing Type
Значение, указывающее тип кадрирования PPP для исходящего вызова:
1 — асинхронное кадрирование;
2 — синхронное кадрирование.
2.12. Call-Clear-Request
Сообщение Call-Clear-Request передается сервером PNS концентратору PAC для индикации планируемого разрыва отдельной сессии. Разрываемое по этому сообщению соединение может быть как входящим, так и исходящим. PAC в ответ на это сообщение передает Call-Disconnect-Notify.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
12 для Call-Clear-Request.
Reserved0
Должно иметь значение 0.
Call ID
Идентификатор Call ID выделенный сервером PNS для этого вызова. Это значение используется взамен Peer’s Call ID, поскольку PNS может не знать этого идентификатора, если соединение разрывается на этапе его организации.
Reserved1
Должно иметь значение 0.
2.13. Call-Disconnect-Notify
Сообщения Call-Disconnect-Notify передаются концентратором PAC серверу PNS. Такое сообщение говорит о разрыве соединения в результате получения концентратором PAC запроса Call-Clear-Request или по иной причине. Задачей сообщения является информирование сервера PNS о разрыве соединения и причине такого разрыва.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message Type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call ID | Result Code | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Call Statistics (128 октетов) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
13 для Call-Disconnect-Notify.
Reserved0
Должно иметь значение 0.
Call ID
Идентификатор Call ID, выделенный PAC для этого вызова. Это значение используется взамен Peer’s Call ID, поскольку PNS может не знать этого идентификатора, если соединение разрывается на этапе его организации.
Result Code
Это значение указывает причину разрыва соединения:
1 (Lost Carrier) — потеря сигнала несущей в линии;
2 (General Error) — разрыв соединения по причине, указанной Error Code;
3 (Admin Shutdown) — разрыв соединения по административным причинам;
4 (Request) — разрыв в результате приема сообщения Call-Clear-Request.
Error Code
Это поле имеет значение 0, если не возникла ошибка общего типа (Result Code = 2). В последнем случае данное поле содержит один из кодов ошибок общего типа, описанных в параграфе 2.1617.
Cause Code
Это поле содержит дополнительную информацию о причине отказа. Значение поля может меняться в зависимости от типа вызова. Для вызовов ISDN используются коды причин Q.931.
Call Statistics
Это поле представляет собой строку символов ASCII с зависящей от производителя статистической информацией, которая может применяться для диагностики. Если размер строки менее 128 октетов, свободные октеты заполняются нулями.
2.14. WAN-Error-Notify
Сообщения WAN-Error-Notify передаются концентраторами PAC серверам PNS для индикации ошибок WAN (ошибочная ситуация на интерфейсе, поддерживающем PPP). Для таких сообщений используются накопительные счетчики. Сообщения этого типа следует передавать только при возникновении реальных ошибок и не чаще одного раза в течение 60 секунд. Счетчики сбрасываются при организации нового вызова.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer's Call ID | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Overruns | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Overruns | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-out Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alignment Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
14 для WAN-Error-Notify.
Reserved0
Должно иметь значение 0.
Peer’s Call ID
Значение Call ID, выделенное сервером PNS для этого вызова.
CRC Errors
Число кадров PPP, принятых с ошибками четности (CRC) с момента организации сессии.
Framing Errors
Число принятых кадров PPP с ошибками кадрирования.
Hardware Overruns
Число случаев переполнения приемных буферов с момента организации сессии.
Buffer Overruns
Число случаев переполнения буферов с момента организации сессии.
Time-out Errors
Число тайм-аутов с момента организации сессии.
Alignment Errors
Число ошибок выравнивания с момента организации сессии.
2.15. Set-Link-Info
Сообщения Set-Link-Info передаются серверами PNS концентраторами PAC для установки согласованных протоколом PPP опций. Поскольку эти опции могут меняться во время сессии, устройства PAC должны обеспечивать возможность динамического изменения своей информации о соединениях и выполнения согласований PPP для активных сессий.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | PPTP Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Message type | Reserved0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer's Call ID | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length
Общий размер сообщения PPTP в октетах с учетом всего заголовка PPTP.
PPTP Message Type
1 для управляющего сообщения.
Magic Cookie
0x1A2B3C4D.
Control Message Type
15 для Set-Link-Info.
Reserved0
Должно иметь значение 0.
Peer’s Call ID
Идентификатор Call ID, выделенный PAC для этого вызова.
Reserved1
Должно иметь значение 0.
Send ACCM
Значение Send ACCM, которое клиенту следует использовать для обработки исходящих пакетов PPP. До получения сообщений этого типа клиенты используют принятое по умолчанию значение 0XFFFFFFFF [7].
Receive ACCM
Значение Receive ACCM, которое клиенту следует использовать для обработки входящих пакетов PPP. До получения сообщений этого типа клиенты используют принятое по умолчанию значение 0XFFFFFFFF [7].
2.16. Коды ошибок общего типа
Коды ошибок общего типа не относятся к каким-либо специфическим запросам PPTP и служат для указания протокольных ошибок и ошибок, связанных с форматом сообщений. Если отклик PPTP указывает в поле Result Code возникновение ошибки общего типа, для определения конкретной ошибки следует обращаться к полю General Error. Определенные в настоящее время коды General Error перечислены ниже:
0 (None)
Нет ошибок.
1 (Not-Connected)
Нет управляющего соединения для данной пары PAC — PNS.
2 (Bad-Format)
Некорректный размер сообщения или значение Magic Cookie.
3 (Bad-Value)
Значение одного из полей выходит за допустимые пределы или резервное поле отлично от 0.
4 (No-Resource)
Недостаточно ресурсов для обработки этой команды в данный момент.
5 (Bad-Call ID)
Значение Call ID некорректно в данном контексте.
6 (PAC-Error)
Специфическая ошибка оборудования в устройстве PAC.
3. Работа протокола управления соединением
В этом разделе описана работа различных функций управления соединениями PPTP и используемые при этом сообщения Control Connection. Протокольные операции управления соединениями упрощаются за счет применения надежного транспорта TCP. На уровне протокола не нужно контролировать порядок доставки и повторную передачу пакетов. Однако само соединение TCP может быть разорвано в любой момент и для таких ситуаций нужен соответствующий механизм восстановления.
Некоторые процедуры восстановления при ошибках являются общими для всех состояний управляющего соединения. Если ожидаемый отклик не приходит в течение 60 секунд, управляющее соединение закрывается, если в документе явно не указано иное поведение. Для упрощения диагностики и поиска неполадок следует обеспечивать запись в системные журналы сведений о причинах разрыва управляющих соединений.
Получение неприемлемо или некорректно форматированного управляющего сообщения следует фиксировать в системном журнале, разрывая такое соединение с последующим восстановлением в известное состояние.
3.1. Состояния управляющего соединения
Управляющие соединения работают на основе стандартного транспорта TCP. Протокол управления соединениями PPTP не различает устройства PNS и PAC, но различает инициаторов и получателей. Инициатором является та сторона, которая первой начала процесс организации соединения TCP. Поскольку оба устройства PAC и PNS могут служить инициатором соединения, возможно возникновение конфликтов TCP. Описание конфликтных ситуаций приведено в параграфе 3.1.3.
3.1.1. Инициатор управляющего соединения (PAC или PNS)
Индикация TCP Open /Передача Start-Control- Connection-Request +-----------------+ +------------------------------------>| wait_ctl_reply | | +-----------------+ | Конфликт/См. (4.1.3) Close TCP V V V Прием Start-Ctl- | +-------------------------------+ | | Connection-Reply | | | | Верная версия ^ V | V +-----------------+ Прием Start-Ctl- | +-----------------+ | idle | Connection-Reply | | established | +-----------------+ Неверная версия | +-----------------+ ^ | V Локальный разрыв | Прием Stop-Control- | | /Передача Stop- | Connection-Request | | Control-Request | /Передача Stop-Control-Reply V V | Close TCP +-----------------+ +-------------------------------------| wait_stop_reply | +-----------------+
idle
В этом состоянии инициатор управляющего соединения пытается организовать соединение TCP с партнером. После создания транспортного соединения TCP инициатор передает сообщение Start-Control-Connection-Request и переходит в состояние wait_ctl_reply.
wait_ctl_reply
Инициатор проверяет наличие попытки организации другого соединения TCP от того же партнера и при обнаружении такой попытки переходит в состояние обработки конфликта, описанное в параграфе 3.1.3.
При получении Start-Control-Connection-Reply это сообщение проверяется на предмет совместимости версий. Если версия в отклике ниже версии в запросе, следует использовать меньшую (более старую) версию, если она поддерживается обеими сторонами. Если в отклике указана более старая версия и она поддерживается инициатором, тот переходит в состояние established. Если в отклике указана более старая и не поддерживаемая версия, инициатору следует передать партнеру сообщение Stop-Control-Connection-Request, а потом перейти в состояние wait_stop_reply.
established
Организованное соединение может быть разорвано по локальным условиям или в результате получения от партнера запроса Stop-Control-Connection-Request. При разрыве по локальным причинам инициатор должен передать сообщение Stop-Control-Connection-Request и перейти в состояние wait_stop_reply.
Если инициатор получает запрос Stop-Control-Connection-Request, ему следует передать ответное сообщение Stop-Control-Connection-Reply и закрыть сообщение TCP, убедившись с том, что финальные данные TCP отправлены.
wait_stop_reply
При получении отклика Stop-Control-Connection-Reply соединение TCP следует закрывать и управляющее соединение переходит в состояние idle.
3.1.2. Ответчик управляющего соединения (PAC или PNS)
Прием Start-Control-Connection-Request Версия не верна/Передача Start-Control-Connection- Reply с кодом ошибки +--------+ | | Прием Control-Connection-Request, версия верна | | /Передача Start-Control-Connection-Reply | | +----------------------------------------+ ^ V ^ V +-----------------+ Прием Start-Ctl- +-----------------+ | Idle | Connection-Request | Established | +-----------------+ /Передача Stop-Reply-+-----------------+ ^ ^ Close TCP V V Локальный разрыв | +-------------------------------------+ | /Передача Stop- | | Control-Conn.- | V Request | +-----------------+ +-------------------------------------| Wait-Stop-Reply | Прием Stop-Control- +-----------------+ Connection-Reply /Close TCP
idle
Получатель в управляющем соединении ждет организации управляющего соединения TCP через порт 1723. После уведомления о создании такого соединения TCP ему следует приготовиться к получению сообщений PPTP. При получении запроса Start-Control-Connection-Request следует проверить номер версии. Если в сообщении указана версия более ранняя, чем версия у получателя, и эта версия поддерживается получателем, тому следует передать сообщение Start-Control-Connection-Reply. Если в сообщении указана более ранняя, но не поддерживаемая версия, получателю следует передать сообщение Start-Connection-Reply, закрыть соединение TCP и перейти в состояние idle. Если версия получателя совпадает с версией в сообщении или старее той, получателю следует передать сообщение Start-Control-Connection-Reply со своим номером версии и перейти в состояние established.
established
Организованное соединение может быть разорвано по локальным условиям или в результате получения от партнера запроса Stop-Control-Connection-Request. При разрыве по локальным причинам инициатор должен передать сообщение Stop-Control-Connection-Request и перейти в состояние wait_stop_reply.
Если инициатор получает запрос Stop-Control-Connection-Request, ему следует передать ответное сообщение Stop-Control-Connection-Reply и закрыть сообщение TCP, убедившись с том, что финальные данные TCP отправлены.
wait_stop_reply
При получении отклика Stop-Control-Connection-Reply следует закрыть соединение TCP, а управляющее соединение переходит в состояние idle.
3.1.3. Конфликты при организации управляющего соединения
Между устройствами PAC и PNS должно быть организовано единственное управляющее соединение. Однако возможны случаи, когда PNS и PAC одновременно попытаются организовать управляющие соединения между собой. При получении запроса Start-Control-Connection-Request через соединение TCP, когда уже был отправлен другой запрос Start-Control-Connection-Request тому же партнеру через другое соединение TCP, возникает конфликт.
В качестве «победителя» при таком конфликте выбирается инициатор с большим значением адреса IP (сравниваются, как 32-битовые целые числа без знака с номером сети в качестве старшего байта). Например, если партнеры используют адреса 192.33.45.17 и 192.33.45.89, при возникновении конфликта «победителем» станет второй. «Проигравший» будет незамедлительно закрывать соединение TCP без передачи каких-либо управляющих сообщений PPTP, а после этого отвечать «победителю» сообщением Start-Control-Connection-Reply. «Победитель» будет ждать отклика Start-Control-Connection-Reply через организованное соединение, а также индикации разрыва открытого «проигравшим» соединения TCP. «Победителю» недопустимо передавать какие-либо сообщения в инициированное «проигравшим» соединение.
3.1.4. Сообщения Keep Alive и таймеры
Управляющее соединение следует закрывать путем разрыва транспортного соединения TCP в следующих случаях:
-
Если управляющее соединение не находится в состоянии established (т. е., не был выполнен обмен сообщениями Start-Control-Connection-Request и Start-Control-Connection-Reply), его следует закрывать по истечении 60 секунд ожидания приема от партнера сообщения Start-Control-Connection-Request или Start-Control-Connection-Reply.
-
Если управляющее соединение находится в состоянии established и от партнера не получено ни одного управляющего сообщения в течение 60 секунд, следует отправить сообщение Echo-Request. Если в течение 60 секунд после этого не будет получен отклик Echo-Reply, управляющее соединение следует закрыть.
3.2. Состояния вызовов
3.2.1. Вопросы синхронизации
Поскольку телефонная сигнализация происходит в реальном масштабе времени, устройствам PNS и PAC следует поддерживать многопотоковую архитектуру, позволяющую обрабатывать сообщения в разных соединениях без очередей и блокировок. Задержка при передаче между PAC и PNS должна быть не более 1 секунды. На диаграммах вызовов и состояний соединений не показаны исключения, вызываемые таймерами. Неявно предполагается, что управляющее соединение TCP поддерживается транспортными сообщениями keep-alive, обеспечивает возможность работы без строго контроля таймеров для управляющих сообщений.
Организация исходящих международных соединений с учетом тренировки модемов и согласования параметров может занимать более 1 минуты, поэтому использование более коротких таймеров не допускается.
Если в течение 1 минут состояние соединения не меняется (за исключением соединений в состояниях idle и established), это считается нарушением работы протокола между партнерами и в результате управляющее соединение в целом должно разрываться и создаваться заново. Все идентификаторы Call ID логически освобождаются при старте соединения. Предполагается, что это поможет предотвратить «зависание» и потерю платных звонков.
3.2.2. Значения Call ID
Каждая пара PAC – PNS выделяет значение Call ID для каждой пользовательской сессии, которую она запрашивает или воспринимает. Эти значения Call ID должны быть уникальными для туннеля между PNS и PAC, к которому относятся сессии. В туннелях к другим партнерам могут использоваться такие же значения Call ID, поэтому получателю пакетов из туннеля следует связывать пользовательскую сессию с туннелем и Call ID. Предполагается, что число возможных значений Call ID для каждого туннеля по крайней мере вдвое превышает максимальное число вызовов, ожидаемое для данного туннеля.
Сессия определяется тремя значениями (PAC, PNS, Call ID).
3.2.3. Входящие вызовы
Сообщения Incoming-Call-Request генерируются концентратором PAC при получении вызовов по соответствующим телефонным линиям. PAC выбирает значение Call ID и порядковый номер, а также указывает тип вызова18. Для модемов всегда следует указывать аналоговый вызов. Для вызовов ISDN следует указывать цифровой тип при использовании неограниченного цифрового обслуживания или адаптации скорости и аналоговый тип при использовании «цифровых модемов». Номер вызывающего, номер для вызова и субадрес также могут включаться в сообщение, если эти значения можно получить из телефонной сети.
После того, как концентратор PAC передаст сообщение Incoming-Call-Request, он ждет отклика от сервера PNS, не отвечая на вызов из телефонной сети. PNS может отказаться от приема вызова в случаях:
-
нехватки ресурсов для обслуживания дополнительной сессии;
-
значения вызывающего или принимающего номера или субадреса не указывают вызов от уполномоченного пользователя;
-
заданный тип вызова не поддерживается или запрещен для использования.
Если сервер PNS принимает решение о восприятии вызова, он передает сообщение Incoming-Call-Reply, которое указывает также размеры окон (см. параграф 4.2). Когда концентратор PAC получает сообщение Outgoing-Call-Reply, он пытается принять вызов, если вызывающая сторона еще не прекратила попытку. Финальное сообщение о соединении от PAC к PNS показывает, что для обоих устройств состояние соединения нужно перевести в established.
Когда пользователь коммутируемой линии «кладет трубку», вызов сбрасывается и концентратор PAC передает сообщение Call-Disconnect-Notify. Если сервер PNS сам желает разорвать соединение, он передает сообщение Call-Clear-Request и ждет для него отклика Call-Disconnect-Notify.
3.2.3.1. Состояния PAC для входящих вызовов
Звонок/Передача Incoming-Call-Request +-----------------+ +----------------------------------------->| wait_reply | | +-----------------+ | Прием Incoming-Call-Reply V V V | Не принимается | | | Прием Incoming- | +--------------------------------+ | | Call-Reply, принимается | | +------------------------------+ | /ответ на вызов; | | | Прерыван./Передача Call- | Передача Call- ^ V V Disconnect-Notify V Connected +-----------------+ +-----------------+ | idle |<-----------------------------| established | +-----------------+ Прием Clear-Call-Request, +-----------------+ разрыв соединения в линии или локальное отключение /Передача Call-Disconnect-Notify
По отношению к входящим вызовам концентратор PAC может находиться в состояниях:
idle
Концентратор PAC детектирует вызов на одном из своих интерфейсов в телефонные сети. Обычно это звонок по аналоговой линии или входящее сообщение Q.931 SETUP на ISDN TE. PAC передает сообщение Incoming-Call-Request и переходит в состояние wait_reply.
wait_reply
PAC получает сообщение Incoming-Call-Reply с указанием неготовности принять вызов (общая ошибка или неприемлемость вызова) и возвращается в состояние idle. Если отклик указывает приемлемость вызова, PAC передает сообщение Incoming-Call-Connected и переходит в состояние established.
established
Обмен данными через туннель. Соединение может быть разорвано в результате:
-
-
события в телефонной сети (PAC передает сообщение Call-Disconnect-Notify);
-
приема сообщения Call-Clear-Request (PAC передает сообщение Call-Disconnect-Notify);
-
локальных причин (PAC передает сообщение Call-Disconnect-Notify).
-
3.2.3.2. Состояния PNS для входящих вызовов
Прием Incoming-Call-Request /Передача Incoming-Call-Reply +-----------------+ Не принимается при ошибке | Wait-Connect | +-----+ +-----------------+ | | Прием Incoming-Call-Req. ^ V V | | /Передача Incom.-Call-Reply OK | | | Прием Incoming- | | +--------------------------------+ | | Call-Connect ^ V ^ V------------------------------+ V +-----------------+ Прием Call-Disconnect- +-----------------+ | Idle | Notify +- | Established | +-----------------+ | +-----------------+ ^ ^ | V Локальный разрыв | +----------------------------+ | /Передача Call-Clear- | Прием Call-Disconnect- | Request | Notify V | +-----------------+ +--------------------------------------| Wait-Disconnect | Прием Call-Disconnect- +-----------------+ Notify
По отношению к входящим вызовам сервер PNS может находиться в состояниях:
idle
Принимается сообщение Incoming-Call-Request. Если запрос не приемлем, в ответ на него концентратору PAC возвращается сообщение Incoming-Call-Reply и сервер PNS остается в состоянии idle. Если запрос Incoming-Call-Request приемлем, передается сообщение Incoming-Call-Reply, указывающее возможность приема вызова в коде результат. Сессия переводится в состояние wait_connect.
wait_connect
Если сессия подключена на концентраторе PAC, он передает сообщение Incoming-Call-Connect серверу PNS и тот переходит в состояние established. PAC может передать сообщение Call-Disconnect-Notify для индикации того, что входящий вызов не может быть принят. Это может происходить, например, в результате обычного голосового вызова на номер концентратора PAC с соответствующим отказом процедуры согласования в модеме.
established
Сессия разрывается приемом сообщения Call-Disconnect-Notify от устройства PAC или передачей запроса Call-Clear-Request. После отправки сообщения Call-Clear-Request сессия переходит в состояние wait_disconnect.
wait_disconnect
После приема сообщения Call-Disconnect-Notify сессия возвращается в состояние idle.
3.2.4. Исходящие вызовы
Исходящие сообщения инициируются PNS и запрашивают у концентратора PAC организацию вызова через интерфейс в телефонную сеть. Имеется только два сообщения для работы с исходящими вызовами – Outgoing-Call-Request и Outgoing-Call-Reply. PNS передает запрос Outgoing-Call-Request, указывающий номер вызываемого абонента и его субадрес, а также значения скорости и параметров окна. Концентратор PAC должен ответить на Outgoing-Call-Request своим сообщением Outgoing-Call-Reply после того, как:
-
соединение будет организовано;
-
при попытке соединения возникнет отказ — нет свободных интерфейсов, удаленный абонент занят или не отвечает, нет сигнала в выбранной для звонка линии.
3.2.4.1. Состояния PAC для исходящих вызовов
Прием Outgoing-Call-Request при ошибке /Передача Outgoing-Call-Reply с Error Code |--------+ | | Прием Outgoing-Call-Request без ошибок | | /Подъем трубки; Набор номера | | +----------------------------------------- ^ V ^ V +-----------------+ Незавершенный вызов +-----------------+ | idle | /Перед. Outgoing-Call- | wait_cs_ans | +-----------------+ Reply с Error Code +-----------------+ ^ ^ или Прием Recv.-Call-Clear-Req. V V Ответ из телефонной линии | | /Send Disconnect Notify| | /Передача Outgoing- | +-------------------------------------+ | Call-Reply. | V | +-----------------+ +-------------------------------------| established | Прием Call-Clear-Request, +-----------------+ локальный разрыв, или разрыв в линии /Положить трубку и предать Call-Disconnect-Notify
По отношению к исходящим вызовам концентратор PAC может находиться в состояниях:
idle
Принят запрос Outgoing-Call-Request. Если при его выполнении возникает ошибка, возвращается сообщение Outgoing-Call-Reply с указанием кода ошибки. В остальных случаях для звонка выделяется канал. После организации вызова концентратор ждет ответа удаленной стороны и переходит в состояние wait_cs_ans.
wait_cs_ans
Если вызов остается не завершенным, передается сообщение Outgoing-Call-Reply с отличным от нуля полем Error Code. Если истекло время ожидания для исходящего вызова, возвращается сообщение Outgoing-Call-Reply с отличным от нуля полем Error Code. Если коммутируемое соединение организовано, возвращается сообщение Outgoing-Call-Reply с индикацией успеха.
established
При получении запроса Call-Clear-Request телефонный вызов следует сбросить с помощью подходящего механизма, а серверу PNS следует направить сообщение Call-Disconnect-Notify. Если соединение было разорвано клиентом или интерфейсом в телефонную сеть, следует передать серверу PNS сообщение Call-Disconnect-Notify.
3.2.4.2. Состояния PNS для исходящих вызовов
Индикация Open Прерывание/передача /Передача Outgoing-Call- Call-Clear- Request +-----------------+ Request +-------------------------------->| Wait-Reply |----------+ | +-----------------+ | | Прием Outgoing-Call-Reply V V Прием Outgoing- | | с Error Code | | Call-Reply | | +-------------------------------+ | нет ошибок | ^ V V | +-----------------+ +-----------------+ | | Idle |<-----------------------------| Established | | +-----------------+ Прием Call-Disconnect- +-----------------+ | ^ Notify V Локальный разрыв | | | /Перед. Call-Clear-| | | Request | | Прием Call-Disconnect- V | | Notify +-----------------+ | +---------------------------------| Wait-Disconnect |<---------+ +-----------------+
По отношению к исходящим вызовам сервер PNS может находиться в состояниях:
idle
Передается сообщение Outgoing-Call-Request концентратору PAC и сессия переходит в состояние wait_reply.
wait_reply
Принимается сообщение Outgoing-Call-Reply с индикацией ошибки и сессия возвращается в состояние idle. Нет активного соединения с телефонной сетью. Если сообщение Outgoing-Call-Reply не говорит об ошибке, организуется телефонное соединение и сессия переходит в состояние established.
established
Сообщение Call-Disconnect-Notify говорит о неудаче телефонного вызова по причине, указанной полями Result Code и Cause Code. Сессия возвращается в состояние idle. Если сервер PNS решает прервать сессию, он передает сообщение Call-Clear-Request концентратору PAC и переходит в состояние wait_disconnect.
wait_disconnect
Ожидание подтверждения разрыва сессии от концентратора PAC. Когда PNS получает сообщение Call-Disconnect-Notify, сессия переходит в состояние idle.
4. Работа туннельного протокола
Пользовательские данные передаются протоколом PPTP в форме пакетов данных PPP. Передаваемые между устройствами PAC и PNS пакеты PPP инкапсулируются с использованием пакетов GRE, которые, в свою очередь, передаются по протоколу IP. Инкапсулированные пакеты PPP являются преимущественно пакетами данных PPP за исключением незначительного числа специфических для среды элементов кадрирования. Не используется флагов HDLC, вставки битов, управляющих символов. Контрольные суммы CRC не передаются через туннель. Пакеты IP, передаваемые через туннели между PAC и PNS имеют структуру, показанную на рисунке.
+--------------------------------+ | Заголовок среды | +--------------------------------+ | Заголовок IP | +--------------------------------+ | Заголовок GRE | +--------------------------------+ | Пакет PPP | +--------------------------------+
4.1. Заголовок Enhanced GRE
Заголовок GRE, используемый в PPTP, незначительно отличается от заданного в текущей спецификации протокола GRE [1, 2]. Основное отличие заключается в добавлении поля Acknowledgment Number, используемого для уведомления о доставке конкретного пакета GRE или группы пакетов на удаленную сторону туннеля. Этот механизм подтверждения не используется совместно с каким-либо повтором передачи пользовательских данных. Он просто служит для определения скорости, с которой передаются через туннель данные конкретной пользовательской сессии. Формат расширенного заголовка GRE показан на рисунке.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (HW) Payload Length | Key (LW) Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (необязат.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number (необязат.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C
(Бит 0) Присутствует контрольная сумма. Устанавливается в 0.
R
(Бит 1) Присутствует маршрутизация. Устанавливается в 0.
K
(Бит 2) Присутствует ключ. Устанавливается значение 1.
S
(Бит 3) Присутствует порядковый номер. Устанавливается 1 при наличии пользовательских данных и 0, если таких данных нет (пакет GRE содержит только подтверждение – Acknowledgment).
s
(Бит 4) Присутствует строго заданный отправителем маршрут. Устанавливается в 0.
Recur
(Биты 5-7) Управление рекурсией. Устанавливается в 0.
A
(Бит 8) Присутствует порядковый номер подтверждения. Устанавливается в 1, если пакет содержит Acknowledgment Number для подтверждения ранее переданных данных.
Flags
( Биты 9-12) Должны устанавливаться в 0.
Ver
( Биты 13-15) Должны устанавливаться в 1 (Enhanced GRE).
Protocol Type
Шестнадцатеричное значение 880B [8].
Key
Применение поля Key определяется реализацией. В PPTP поле ключа используется, как показано ниже:
Payload Length
(2 старших октета поля Key) Размер данных без учета заголовка GRE.
Call ID
(Два младших октета) Содержит значение Peer’s Call ID для сессии, к которой относится пакет.
Sequence Number
Содержит порядковый номер данных, используется при установленном (1) флаге S (бит 3).
Acknowledgment Number
Содержит наибольший порядковый номер пакета GRE, полученного передающим партнером в этой пользовательской сессии. Присутствует при установленном (1) флаге A (бит 8).
Раздел данных содержит пакет данных PPP без каких-либо специфических элементов кадрирования.
Порядковые номера являются номерами пакетов. В начале сессии для стартового порядкового номера устанавливается нулевое значение. Каждому пакету в данной пользовательской сессии, содержащему данные (и бит S=1) присваивается следующий порядковый номер.
Этот протокол позволяет передавать подтверждения вместе с данными, что повышает эффективность работы протокола и требования к размеру буферного пространства.
4.2. Протокол скользящего окна
Протокол скользящего окна на пути передачи данных PPTP служит для управления потоком данных на каждой стороне. Расширенный протокол GRE позволяет «прицеплять» подтверждения к пакетам данных. Подтверждения могут также передаваться отдельно от пакетов данных. Основной целью применения протокола скользящего окна является управления потоком — повторная передача конечными точками туннеля не производится.
4.2.1. Начальный размер окна
Хотя каждая сторона указывает максимальный размер приемного окна, на начальном этапе передачи данных рекомендуется пользоваться консервативной моделью. Размер начального окна на передающей стороне устанавливается равным половине максимального размера окна запрошенного получателем, но не менее 1 пакета. Передатчик останавливает отправку пакетов, когда число пакетов, ожидающих подтверждения, становится равным текущему размеру окна. По мере того, как получатель «перерабатывает» каждое окно, размер окна у отправителя увеличивается на 1 пакет, пока не будет достигнут максимум. Этот метод позволяет предотвратить лавинообразный рост трафика в загруженной сети на начальном этапе передачи.
4.2.2. Сужение окна
При возникновении тайм-аута для пакета отправитель снижает вдвое размер своего окна передачи. Дробная часть размера окна округляется вверх, минимальный размер окна составляет 1 пакет.
4.2.3. Расширение окна
При каждой передаче окна пакетов без тайм-аута размер окна передачи увеличивается на 1 пакет, пока не будет достигнуто максимальное значение, переданное другой стороне при организации соединения. Как было отмечено выше, возникновение тайм-аута не вызывает повторной передачи. После тайм-аута передача возобновляется с окном, размер которого составляет половину от размера окна при возникновении тайм-аута и увеличивается на единицу каждый раз, когда окно передачи будет подтверждено без тайм-аутов.
4.2.4. Переполнение окна
Когда приемное окно переполняется в результате получения слишком большого числа пакетов, избыточные пакеты отбрасываются. Таких ситуаций не должно возникать, если если процедуры скользящего окна работают корректно на стороне отправителя и получателя. Предполагается, что на передающей стороне пакеты буферизуются для передачи и при заполнении буфера восприятие пакетов от их источника приостанавливается.
4.2.5. Подтверждение множества пакетов
Одним из свойств протокола скользящего окна PPTP является возможность одновременного подтверждения множества пакетов. Подтвержденными считаются все пакеты, порядковые номера которых не больше номера, указанного в подтверждении. Расчеты тайм-аутов выполняются с использованием времени для пакета с максимальным номером, который будет подтверждаться.
Адаптивный расчет тайм-аута выполняется только при получении пакетов Acknowledgment. При использовании многопакетных подтверждений издержки на расчет тайм-аутов снижаются. От концентраторов PAC не требуется передачи многопакетных подтверждений, они могут индивидуально подтверждать каждый пакет, доставленный клиенту PPP.
4.3. Нарушение порядка пакетов
Иногда при доставке пакетов через сложную межсетевую среду может меняться порядок их доставки. Рассмотрим в качестве примера случай, когда PNS передает пакеты 0 – 5 концентратору PAC. В результате изменения маршрута пакет 4 приходит в PAC до пакета 3. PAC подтверждает пакет 4 и может предположить потерю пакета 3. Такое подтверждение позволяет переместить окно за пределы пакета 4.
Когда концентратор PAC получит пакет 3, он должен отказаться от его передачи соответствующему клиенту PPP. Такая передача может вызвать проблемы, поскольку протокол PPP предполагает упорядоченную доставку пакетов. PPP корректно обрабатывает ситуации с потерей пакетов, но не с нарушением порядка их доставки, поэтому пакеты с нарушением порядка доставки между устройствами PNS и PAC должны отбрасываться без изменения, если получатель не может сам восстановить корректный порядок. При получении пакета 5 концентратор PAC подтверждает его, поскольку порядковый номер превышает ранее подтвержденный номер 4. Пакеты с дубликатами порядковых номеров не должны появляться, поскольку устройства PAC и PNS никогда не передают повторно пакеты GRE. Отказоустойчивым реализациям следует отбрасывать без уведомления дубликаты пакетов GRE при их получении.
4.4. Тайм-ауты подтверждений
PPTP использует скользящие окна и тайм-ауты для управления потоком данных пользовательских сессий через межсетевую среду и эффективной буферизации, позволяющей предотвратить переполнение входных буферов на каналах данных между PAC и PNS. Протокол PPTP требует использования тайм-аута для восстановления при отбрасывании данных или пакетов подтверждений. Конкретная реализация механизма тайм-аутов выбирается разработчиками. Предлагается применять адаптивный механизм с изменением значений тайм-аута для контроля перегрузок. Свойства предлагаемого здесь механизма приведены ниже.
-
Независимые значения тайм-аута для каждой сессии. Устройство (PAC или PNS) будет поддерживать и рассчитывать значения тайм-аута для каждой активной сессии.
-
Устанавливаемое администратором максимальное значение тайм-аута (MaxTimeOut) уникальное для каждого устройства.
-
Адаптивный механизм установки значений тайм-аута, компенсирующий изменения пропускной способности. Для снижения издержек на обработку пакетов разработчики могут отказаться от пересчета значений тайм-аута при получении каждого подтверждения. В результате снизятся издержки, но тайм-аут не сможет быстро адаптироваться к изменениям в сети.
-
Таймер отсрочки тайм-аута для снижения перегрузок. Значение отсрочки ограничивается настраиваемым максимум для тайм-аута. Таймер отсрочки запускается при каждом тайм-ауте для подтверждения.
В общем случае этот механизм обеспечивает желаемое поведение с быстрым восстановлением после тайм-аутов и медленным ростом значения тайм-аута по мере доставки пакетов без возникновения тайм-аута.
Ниже приведены некоторые определения.
-
Задержка при обработке пакетов (PPD19) – интервал времени, требуемого для каждой из сторон на обработку максимального объема данных в их скользящем окне приема. При организации вызова выполняется обмен значениями PPD между устройствами PAC и PNS. Для PNS это значение должно быть малым, а для PAC, организующих модемные соединения, задержка может быть достаточно большой.
-
Выборка (Sample) — фактическое время, прошедшее до получения подтверждения пакета. Значение Sample измеряется, а не рассчитывается.
-
Время кругового обхода (RTT20) – оценочное значение интервала времени, в течение которого приходит подтверждение (Acknowledgment) для данного отправленного пакета. Когда соединение организовано через локальную сеть, этот интервал очень мал (если не 0). Когда канал организуется через Internet, эта задержка может быть достаточно велика и меняться в широких пределах. Значение RTT является адаптивным — оно будет изменяться с учетом PPD и изменения задержек в сети.
-
Адаптивный тайм-аут (ATO21) – время, которое должно пройти до того, как подтверждение станет считаться потерянным. После возникновения тайм-аута скользящее окно уменьшается и значение ATO снижается.
Параметр PPD представляет собой 16-битовое слово, представляющее задержку в десятых долях секунды 64 соответствует 6,4 сек.). Обмен значениями выполняется на этапе Call Control. Протокол задает лишь обмен значениями параметров, не указывая способа расчета значений, который определяется реализацией. Значение параметра может быть статическим. Обмен параметрами PPD должен выполняться на этапе организации соединения даже в случае использования стационарных значений. Один из способов расчета PPD показан ниже.
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate PPD = PPD' + PACFudge
Параметр Header задает общий размер заголовков IP и GRE (36 байт). Параметр MTU задает значение MTU для всего пути между устройствами PAC и PNS. Параметр WindowSize представляет число пакетов в скользящем окне, которое зависит от реализации. Задержка в межсетевой среде может использоваться для выбора размера окна, достаточного для эффективного заполнение сеансового «канала». Константа 8 служит для пересчета октетов в биты (в предположении задания ConnectRate в бит/сек). Если ConnectRate задается в байт/сек, число 8 следует опустить. Параметр PACFudge не требуется, но может быть использован для учета суммарных издержек на обработку в устройстве PAC.
Значение PPD используется в качестве «затравки» адаптивного алгоритма с начальным значением RTT[n-1].
4.4.1. Расчет тайм-аута адаптивных подтверждений
Мы должны решить, в течение какого времени можно ожидать подтверждения. Если установить слишком большой тайм-аут, информации о потере придется ждать необоснованно долго. Если время ожидания слишком мало, тайм-аут может возникать до прибытия подтверждения. Время ожидания подтверждений следует устанавливать с учетом изменяющихся условий в сети.
Приведенный ниже алгоритм основан на реализации TCP 1989 года и описан в [11]. Параметр n указывает номер итерации, а n-1 указывает значения из предыдущего расчета.
DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut))
DIFF представляет различие (ошибку) между последней оценкой времени кругового обхода и измеренным значением. DIFF вычисляется при каждой итерации.
DEV представляет оценку среднего отклонения (mean deviation) и является аппроксимацией стандартного отклонения. Значение DEV рассчитывается при каждой итерации и сохраняется для использования в следующей итерации. Изначально устанавливается нулевое отклонение.
RTT представляет оценку времени кругового обхода для среднего пакета. RTT рассчитывается при каждой итерации и сохраняется для использования в следующей итерации. Изначально устанавливается значение PPD.
ATO представляет адаптивный тайм-аут для следующего передаваемого пакета. Значение ATO вычисляется при каждой итерации и ограничено снизу функцией MIN, а сверху — конфигурационным параметром MaxTimeOut.
Alpha представляет коэффициент для среднего значения и обычно имеет значение 1/8 (0,125).
Beta представляет коэффициент для отклонения и обычно имеет значение 1/4 (0.250).
Chi представляет коэффициент для тайм-аута и обычно имеет значение 4.
Для того, чтобы не выполнять операции деления с дробными коэффициентами, можно масштабировать высь комплект уравнений. Для предложенных значений коэффициентов можно избавиться от множества операций деления с помощью общего масштабного коэффициента 8. С целью упрощения расчетов все коэффициенты представлены степенями числа 2, чтобы операции умножения и деления можно было заменить операциями сдвига.
4.4.2. Контроль насыщения — подбор тайм-аута
В этом параграфе описано изменение расчета ATO для случая возникновения тайм-аута. В таких ситуациях значение времени ожидания следует быстро увеличивать. Хотя в результате тайм-аута пакеты GRE не передаются повторно, значение тайм-аута следует увеличивать, не выходя за установленный максимум. Для компенсации изменения задержек в межсетевой среде должна быть реализована стратегия увеличения времени ожидания по возникновению тайм-аута (отметим, что в дополнение к росту тайм-аута выполняется сокращение размера окна, описанное ниже). Для интервала, в котором наблюдался тайм-аут, новое значение ATO вычисляется по формулам, приведенным ниже.
RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut))
В этом расчете ATO только два значения, вносящих вклад в ATO сохраняются для следующей итерации и рассчитываются. Значение RTT меняется коэффициентом delta, значение DEV остается неизменным. Параметр DIFF не используется в этом расчете. Для коэффициента Delta, на который умножается параметр RTT, предлагается значение 2.
5. Вопросы безопасности
Безопасность пользовательских данных при передаче через туннель PPP обеспечивается протоколом PPP, как и аутентификация партнеров PPP.
Поскольку для сообщений в управляющем канале PPTP не обеспечивается аутентификации и защиты целостности, атакующий может перехватывать нижележащее соединение TCP. Возможно также создание ложных управляющих соединений и изменение легитимных сообщений без обнаружения таких событий.
Пакеты GRE, формирующие туннель, сами по себе не защищены криптографически. Поскольку согласование PPP выполняется через туннель, атакующий может перехватить это согласование и повлиять на него.
Пока данные PPP не защищены криптографически, они могут быть перехвачены, прочитаны и изменены.
6. Адреса авторов
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
EMail: kory@ascend.com
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
EMail: gurdeep@microsoft.com
William Verthein
U.S. Robotics/3Com
Jeff Taarud
Copper Mountain Networks
W. Andrew Little
ECI Telematics
Glen Zorn
Microsoft Corporation
Redmond, WA
EMail: glennz@microsoft.com
Перевод на русский язык
Николай Малых
7. Литература
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, “Generic Routing Encapsulation (GRE)”, RFC 1701, October 1994.
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, “Generic Routing Encapsulation (GRE) over IPv4 Networks”, RFC 1702, October 1994.
[3] Lloyd, B. and W. Simpson, “PPP Authentication Protocols”, RFC 1334, October 1992.
[4] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.
[5] Postel, J., “User Data Protocol”, STD 6, RFC 768, August 1980.
[6] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 1700, October 1994. См. также http://www.iana.org/numbers.html
[7] Simpson, W., editor, “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, July 1994.
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[9] Simpson, W., “PPP Challenge Handshake Authentication Protocol (CHAP)”, RFC 1994, August 1996.
[10] Blunk, L. and J Vollbrecht, “PPP Extensible Authentication Protocol (EAP)”, RFC 2284, March 1998.
[11] Stevens, R., “TCP/IP Illustrated, Volume 1”, p. 300, Addison-Wesley, 1994.
[12] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
8. Полное заявление авторских прав
Copyright (C) The Internet Society (1999). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Point to Point Protocol.
2Network Access Server.
3Virtual Private Network — виртуальная частная сеть.
4PPTP Network Server — сетевой сервер PPTP.
5PPTP Access Concentrator — концентратор доступа PPTP.
6Generic Routing Encapsulation — базовая инкапсуляция маршрутизации.
7Network Access Server.
8Point-to-Point-Protocol.
9Link Control Protocol — протокол управления каналом.
10Network Control Protocol.
11Protocol Data Unit – модуль данных протокола.
12В оригинале ошибочно указан параграф 2.2. См. http://www.rfc-editor.org/errata_search.php?rfc=2637&eid=4790. Прим. перев.
13В оригинале ошибочно указан параграф 2.2. См. http://www.rfc-editor.org/errata_search.php?rfc=2637&eid=4791. Прим. перев.
14В оригинале ошибочно указан параграф 2.2. См. http://www.rfc-editor.org/errata_search.php?rfc=2637&eid=4792. Прим. перев.
15В оригинале ошибочно указан параграф 2.2. См. http://www.rfc-editor.org/errata_search.php?rfc=2637&eid=4793. Прим. перев.
16В оригинале ошибочно указан параграф 2.2. Прим. перев.
17В оригинале ошибочно указан параграф 2.2. Прим. перев.
18Аналоговый или цифровой. Прим. перев.
19Packet Processing Delay.
20Round-Trip Time.
21Adaptive Time-Out.
