Формат кадра пакетного режима

Рисунок 4.2.1.10 Формат кадра пакетного режима

В скобках на рисунке указаны размеры полей в байтах. Поле тип потока в данное время может содержать только код 0x02 и означает, что передаются длинные блоки пакетов. Поле идентификатор отправителя является случайным числом и представляет собой уникальный идентификатор канала, работающего в пакетном режиме. Код этого поля формируется отправителем и не должен равняться нулю. Идентификатор канала получателя также случайное число, но задается адресатом и также не должно содержать нуль. Поле номер пакета по порядку служит для отслеживания текущей пакетной операции и увеличивается на единицу для каждого нового пакета. Поле время задержки передачи означает величину задержки между отправкой пакетов и измеряется в сотнях микросекунд. Поле номер блока пакетов идентифицирует принадлежность пакета к конкретному блоку (данные, посылаемые по запросу, образуют один блок). При установлении связи код этого поля делается равным нулю. В дальнейшем при выполнении каждого запроса его значение увеличивается на 1. Поле порядковый номер подтверждения содержит номер блока пакетов, ожидаемый следующим. Поле служит для контроля доставки блоков пакетов. Поле полная длина блока пакетов задает длину блока в байтах и равно сумме длин всех пакетов в блоке. Поле указатель блока пакетов определяет положение конкретного пакета, указатель равный нулю говорит о том, что это первый пакет. Поле длина блока задает длину блока пакетов в октетах. Поле элементы списка фрагментов задает число элементов, пропущенных в процессе реализации пакетной сессии. Если это число равно нулю, пропущенных фрагментов не было. Поле функция определяет разновидность операции (чтение или запись), реализуемой в данной сессии. Последующие поля служат для операций с файлами.

Формат поля значения атрибута AVP

Рисунок 7. Формат поля значения атрибута AVP

Результирующий код представляет собой целое число без знака длиной в 2 октета. Опционный код ошибки представляет собой 2-октетное целое число без знака. Опционное сообщение об ошибке поясняет код ошибки. Присутствие кода ошибки и сообщения определяется полем длины AVP. Сообщение об ошибке содержит произвольную строку текста, пригодного для чтения, характеризующего ситуацию. Читабельный текст во всех сообщений об ошибке должен быть представлен в кодировке UTF-8, для языка по умолчанию [RFC2277].

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина равна 8, если в сообщении нет кода ошибки и нет сообщения об ошибке, 10, если имеется код ошибки, но нет сообщения об ошибке, или 10 + длина сообщения об ошибке, если имеется код и сообщение об ошибке. Определенные значения кодов результата для сообщения StopCCN перечислены ниже:

0 - Зарезервировано

1 – Общий запрос ликвидации управляющего соединения

2 – Общая ошибка – код ошибки указывает на разновидность возникшей проблемы

3 – Управляющий канал уже существует

4 - Источник запроса не авторизован для формирования управляющего канала

5 – Версия протокола источника запроса не поддерживается. Код ошибки указывает на более высокую поддерживаемую версию

6 – Источник запроса прекратил работу (shutdown)

7 – Ошибка машины конечных состояний

Определены следующие значения кодов результата для сообщений CDN:

0 - Зарезервировано

1 – Вызов прерван из-за потери несущей.

2 - Вызов прерван по причине, указанной в коде ошибки

3 - Вызов прерван по административным причинам

4 - Вызов не прошел из-за отсутствия необходимых условий (временная причина)

5 - Вызов не прошел из-за отсутствия необходимых условий (постоянная причина)

6 – Неверное место назначения

7 - Вызов не прошел из-за невозможности детектировать несущую

8 - Вызов не прошел из-за регистрации сигнала “занято”

9 - Вызов не прошел из-за отсутствия постоянного гудка (разрешение набора номера)

10 – Вызов не состоялся в пределах временного интервала, выделенного LAC

11 – Вызов реализовал соединение, но не обнаружено соответствующих кадров

Коды ошибок, определенные ниже, относятся к типам ошибок, которые не являются специфическими для любого конкретного L2TP-запроса, и относятся скорее к ошибкам протокола или формата сообщения. Если L2TP-отклик указывает в своем коде результата, что произошла общая ошибка, для выяснения причины должен быть проанализирован общий код ошибки. В настоящее время определены общие коды ошибки и их значение:

0 – Отсутствие ошибки.

1 – Пока нет контрольного соединения для данной пары LAC-LNS.

2 – Длина не корректна.

3 – Одно из значений полей находится вне допустимых пределов или зарезервированное поле имеет ненулевое значение.

4 – Недостаточно ресурсов для осуществления операции

5 – ID-сессии не верно в данном контексте

6 – Произошла ошибка в LAC, специфическая для оборудования производителя.

7 – Испробовать другое место назначение. Если LAC знает о других возможных местах назначения LNS, следует попробовать одно из них. Это может быть использовано для управления LAC, базирующемся на LNS-политике, например, в случае существования многоканальных PPP.

8 – Сессия или туннель были аннулированы (shutdown) из-за получения неизвестной AVP с битом M=1 (смотри раздел 4.2). Сообщение об ошибке должно содержать атрибут некорректного AVP в читаемой текстовой форме.

Когда используется код общей ошибки = 6, дополнительная информация об ошибке должна быть помещена в поле сообщения об ошибке.

4.4.3. AVP управления контрольным соединением

Версия протокола (SCCRP, SCCRQ)

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

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ver	Rev

Формат заголовка LP

Рисунок 3. Формат заголовка L2TP

Бит тип (T) характеризует разновидность пакета. Он устанавливается равным 0 для информационных сообщений и 1 – для управляющих.

Если бит длины (L) равен 1, поле длина присутствует. Для управляющих сообщений этот бит должен быть равен 1.

Биты x зарезервированы для будущих применений. Все зарезервированные биты должны быть установлены равными 0 для исходящих сообщений и игнорироваться для входящих.

Если бит последовательности (S) равен 1, поля Ns и Nr присутствуют. Бит S для управляющих сообщений должен быть равен 1.

Если бит смещения (O) равен 1, поле величины смещения присутствует. Бит O для управляющих сообщений должен быть равен 0.

Если бит приоритета Р равен 1, это информационное сообщение должно обслуживаться с предпочтением при обработке очередей и передаче. Запрос эхо LCP (Link Control Protocol) используется для канала, в качестве контроля keepalive, его следует посылать с битом приоритета равным 1. Без этого, временные периоды локальной перегрузки могут вызвать интерференцию с сообщениями keepalive и потерю связи. Эта особенность характерна только для информационных сообщений. Бит P должен быть равен 0 для всех управляющих сообщений.

Поле Ver должно быть равно 2, указывая версию заголовка информационного сообщения L2TP. Значение 1 зарезервировано для детектирования пакетов L2F [RFC-2341], в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля Ver должны отбрасываться. Поле длина указывает общую длину сообщения в октетах.

ID-туннеля содержит идентификатор управляющего соединения. Идентификаторы туннеля L2TP имеют только локальное значение. То есть, разные концы одного туннеля должны иметь разные ID. ID-туннеля в каждом сообщении должно быть тем, которое ожидает получатель. ID-туннеля выбираются при формировании туннеля.

ID-сессии определяет идентификатор для сессии данного туннеля. Сессии L2TP именуются с помощью идентификаторов, которые имеют только локальное значение.
ID-сессии в каждом сообщении должно быть тем, которое ожидает получатель. ID-сессии выбираются при формировании сессии.

Ns определяет порядковый номер информационного или управляющего сообщения, начиная с нуля и увеличиваясь на 1 (по модулю 216) для каждого посланного сообщения. Смотри разделы 5.8 и 5.4.

Nr содержит порядковый номер, который ожидается для следующего сообщения. Таким образом, Nr делается равным Ns последнего по порядку полученного сообщения плюс один (по модулю 216). В информационных сообщениях, Nr зарезервировано и, если присутствует (как это определяется S- битом), должно игнорироваться при получении. Смотри раздел 5.8.

Поле величина смещения (Offset Size), если имеется, специфицирует число октетов после заголовка L2TP, где должно начинаться поле данных. Содержимое заполнителя смещения не определено. Если поле смещения присутствует, заголовок L2TP завершается после завершающего октета заполнителя смещения.

3.2. Типы управляющих сообщений

Тип сообщения AVP (смотри раздел 4.4.1) определяет специфический тип посылаемого управляющего сообщения.

В данном документе определены следующие типы управляющих сообщений (смотри разделы 6.1 - 6.14):

Управление контрольным соединением

0	(зарезервировано)
1	(SCCRQ)	Start-Control-Connection-Request
2	(SCCRP)	Start-Control-Connection-Reply
3	(SCCCN)	Start-Control-Connection-Connected
4	(StopCCN)	Stop-Control-Connection-Notification
5	(зарезервировано)
6	(HELLO)	Hello

Управление вызовами (Call Management)

7	(OCRQ)	Outgoing-Call-Request
8	(OCRP)	Outgoing-Call-Reply
9	(OCCN)	Outgoing-Call-Connected
10	(ICRQ)	Incoming-Call-Request
11	(ICRP)	Incoming-Call-Reply
12	(ICCN)	Incoming-Call-Connected
13	(зарезервировано)
14	(CDN)	Call-Disconnect-Notify

Сообщения об ошибках

(WEN)

WAN-Error-Notify

Управление сессией PPP

(SLI)

Set-Link-Info

Литература

9 Литература

1.	Ю. В. Прохоров, Ю. А. Розанов. Теория вероятностей. Основные понятия, предельные теоремы, случайные процессы. Наука, Глав. Ред. Физмат литературы, М. 1967, серия “Справочная математическая библиотека”.
2.	Guide to Network Resource Tools. EARN Association, Sept. 15, 1993, V2.0. (ISBN 2- 910286-03-7).
3.	Douglas E. Comer, Internetworking with TCP/IP, Prentice Hall, Englewood Cliffs, N.J. 07632, 1988
4.	Uyless Black, TCP/IP and Related Protocols, McGraw-Hill, Inc, New York. 1992
5.	Feinler, E., et al, DDN Protocol Handbook, DDN Network Information Center, SRI International, Ravenswood Avenue, Menlow Park, California, USA, 1985
6.	Spider Systems, Ltd., "Packets and Protocols", Stanwell Street, Edinburgh, UK. EH6 5NG, 1990.
7.	Tony Bates, et al, "Representation of IP Routing Polices in a Routing Registry" (RIPE-181.txt, October 1994)
8.	A. N. Bobyshev, S. I. Burov, M. Ernst, A. I. Kravtsov, A. O. Saphonov, Yu. A. Semenov "ITEPNET to Internet communication", ITEP III92.
9.	Robert J. T. Morris "Neural Network Control of Communications Systems" IEEE Transactions on Neural Networks, Vol. 5, No. 4, July 1944.
10.	Paul J. Fortier, Handbook of LAN Technology. 2-nd Edition, McGraw-Hill, 1992
11.	W.Richard Stevens "TCP/IP Illustrated", Addison-Wesley Publishing Company, 1994.
12.	Matthew Flint Arnett, Mike Coulombe, et al. Inside TCP/IP, Second Edition, New Riders Publishing, 1995
13.	Лаура Ф. Чаппелл и Дэн Е. Хейкс. Анализатор локальных сетей NetWare (Руководство Novell), Москва, Изд. “ЛОРИ”, 1995.
14.	А. В. Фролов и Г. В. Фролов, Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS, Москва, “Диалог-МИФИ”, 1993
15.	К. Джамса, К. Коуп, Программирование для INTERNET в среде Windows, Санкт-Петербург, “ПИТЕР”, 1996.
16.	ISDN How to get a high-speed connection to the Internet, Charles Summers, Bryant Dunetz, “John Wiley @ Sons, Inc.”
17.	ISDN Explained, Worldwide Network and Applications Technology, 2 edition, John M. Griffiths, John Wiley & sons.
18.	ISDN. Цифровая сеть с интеграцией служб. Понятия, методы, системы. П. Боккер, Москва, Радио и связь, 1991.
19.	С. Вильховченко, Модем 96. Выбор, настройка и использование. Москва, ABF, 1995.
20.	Справочник “Протоколы информационно-вычислительных сетей”. Под ред. И. А. Мизина и А. П. Кулешова, Радио и связь, Москва 1990.
21.	Douglas E. Comer, Internetworking with TCP/IP, Prentice Hall, Englewood Cliffs, N.J. 07632, 1988
22.	Craig Hunt, TCP/IP Network Administration, O’Reilly Associates, Inc., Sebastopol, USA, 1992
23.	А. В. Фролов и Г.В. Фролов, Модемы и факс-модемы. Программирование для MS-DOS и Windows. Москва, “Диалог-МИФИ”, 1995.
24.	Семенов Ю. А. “Протоколы и ресурсы INTERNET” “Радио и связь”, Москва, 1996
25.	Семенов Ю. А. “Сети Интернет. Архитектура и протоколы”, СИРИНЪ, 1998.
26.	А. Н. Назаров, М.В. Симонов, “ATM-технология высокоскоростных сетей” ЭКО-ТРЕНДЗ, Москва 1998.
27.	Н. Н. Слепов, “Синхронные цифровые сети SDH” ЭКО-ТРЕНДЗ, Москва 1998.
28.	"Интернет. Всемирная компьютерная сеть. Практическое пособие и путеводитель". Москва 1995, изд. "Синтез".
29.	"World Wide Web. Всемирная Информационная паутина в сети Интернет". Практическое руководство. МГУ, 1995.
30.	Эд Крол “Все об INTERNET” BNV, Киев 1995.
31.	Пол Гилстер "Навигатор INTERNET. Путеводитель для человека с компьютером и модемом", Москва 1995.
32.	С. Клименко, В. Уразметов "Internet. Среда обитания информационного общества". РФФИ, Информационные системы в науке.
33.	Лаем Куин, Ричард Рассел, Fast Ethernet, bhv, Киев, 1998.
34.	Тимоти Паркер, Освой самостоятельно TCP/IP. Бином, Москва 1997.
35.	Дональд Дж. Стерлинг, Волоконная оптика. Техническое руководство. Изд. “ЛОРИ”, Москва, 1998
36.	Дж. Гауэр, Оптические системы связи. Москва, “Радио и связь”, 1989.
37.	Стивен Спейнаур и Валери Куэрсиа. Справочник WEB-мастера, BHV, Киев, 1997.
38.	Lincoln D. Stein, Web Security: a step-by-step reference guide, Addison-Wesley, 1997
39.	К.Шеннон, Работы по теории информации и кибернетике, Москва,"Изд. иностранной литературы", 1963
40.	В.Е.Котов, Сети Петри,"Наука", Москва, Глав. ред. физ-мат. лит., 1984
41.	Лайза Хендерсон, Том Дженкинс, Frame Relay межсетевые взаимодействия, Москва, "Горячая линия - Телеком", 2000

Локально адаптивный алгоритм сжатия

2.6.2 Локально адаптивный алгоритм сжатия

Этот алгоритм используется для кодирования (L,I), где L строка длиной N, а I – индекс. Это кодирование содержит в себе несколько этапов.

1. Сначала кодируется каждый символ L с использованием локально адаптивного алгоритма для каждого из символов индивидуально. Определяется вектор целых чисел R[0],…,R[N-1], который представляет собой коды для символов L[0],…,L[N-1]. Инициализируется список символов Y, который содержит в себе каждый символ из алфавита Х только один раз. Для каждого i = 0,…,N-1 устанавливается R[i] равным числу символов, предшествующих символу L[i] из списка Y. Взяв Y = [‘a’,’b’,’c’,’r’] в качестве исходного и L = ‘caraab’, вычисляем вектор R: (2 1 3 1 0 3).

2. Применяем алгоритм Хафмана или другой аналогичный алгоритм сжатия к элементам R, рассматривая каждый элемент в качестве объекта для сжатия. В результате получается код OUT и индекс I.

Рассмотрим процедуру декодирования полученного сжатого текста (OUT,I).

Здесь на основе (OUT,I) необходимо вычислить (L,I). Предполагается, что список Y известен.

Сначала вычисляется вектор R, содержащий N чисел: (2 1 3 1 0 3).

Далее вычисляется строка L, содержащая N символов, что дает значения R[0],…,R[N-1]. Если необходимо, инициализируется список Y, содержащий символы алфавита X (как и при процедуре кодирования). Для каждого i = 0,…,N-1 последовательно устанавливается значение L[i], равное символу в положении R[i] из списка Y (нумеруется, начиная с 0), затем символ сдвигается к началу Y. Результирующая строка L представляет собой последнюю колонку матрицы M. Результатом работы алгоритма будет (L,I). Взяв Y = [‘a’,’b’,’c’,’r’] вычисляем строку L = ‘caraab’.

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

Для того чтобы сжать строку S, сначала сформируем строку S’, которая является объединением S c EOF, новым символом, который не встречается в S. После этого используется стандартный алгоритм к строке S’. Так как EOF отличается от прочих символов в S, суффиксы S’ сортируются в том же порядке, как и вращения S’. Это может быть сделано путем построения дерева суффиксов, которое может быть затем обойдено в лексикографическом порядке для сортировки суффиксов. Для этой цели может быть использован алгоритм формирования дерева суффиксов Мак-Крейгта. Его быстродействие составляет 40% от наиболее быстрой методики в случае работы с текстами. Алгоритм работы с деревом суффиксов требует более четырех слов на каждый исходный символ. Манбер и Майерс предложили простой алгоритм сортировки суффиксов строки. Этот алгоритм требует только двух слов на каждый входной символ. Алгоритм работает сначала с первыми i символами суффикса а за тем, используя положения суффиксов в сортируемом массиве, производит сортировку для первых 2i символов. К сожалению этот алгоритм работает заметно медленнее.

В работе [1] предложен несколько лучший алгоритм сортировки суффиксов. В этом алгоритме сортируются суффиксы строки S, которая содержит N символов S[0,…,N-1].

Пусть k число символов, соответствующих машинному слову. Образуем строку S’ из S путем добавления k символов EOF в строку S. Предполагается, что EOF не встречается в строке S.

Инициализируем массив W из N слов W[0,…,N-1] так, что W[i] содержат символы S’[i,…,i+k-1] упорядоченные таким образом, что целочисленное сравнение слов согласуется с лексикографическим сравнением для k-символьных строк. Упаковка символов в слова имеет два преимущества: это позволяет для двух префиксов сравнить сразу k байт и отбросить многие случаи, описанные ниже.

Инициализируется массив V из N целых чисел. Если элемент V содержит j, он представляет собой суффикс S’, чей первый символ равен S’[j]. Когда выполнение алгоритма завершено, суффикс V[i] будет i-ым суффиксом в лексикографическом порядке.

Инициализируем целочисленный массив V так, что для каждого i = 0,…,N-1 : V[i]=i.

Сортируем элементы V, используя первые два символа каждого суффикса в качестве ключа сортировки. Далее для каждого символа ch из алфавита выполняем шаги 6 и 7. Когда эти итерации завершены, V представляет собой отсортированные суффиксы S и работа алгоритма завершается.

Для каждого символа ch’ в алфавите выполняем сортировку элементов V, начинающихся с ch, за которым следует ch’. В процессе выполнения сортировки сравниваем элементы V путем сопоставления суффиксов, которые они представляют при индексировании массива W. На каждом шаге рекурсии следует отслеживать число символов, которые оказались равными в группе, чтобы не сравнивать их снова. Все суффиксы, начинающиеся с ch, отсортированы в рамках V.

Для каждого элемента V[i], соответствующего суффиксу, начинающемуся с ch (то есть, для которого S[V[i]] = ch), установить W[V[i]] значение с ch в старших битах и i в младших битах. Новое значение W[V[i]] сортируется в те же позиции, что и старые значения.

Данный алгоритм может быть улучшен различными способами. Одним из самоочевидных методов является выбор символа ch на этапе 5, начиная с наименьшего общего символа в S и предшествующий наиболее общему.

Ссылки

M.Burrows and D.J.Wheeler. A block-sorting Lossless Data Compression Algorithm. Digital Systems Research Center. SRC report 124. May 10, 1994.

J.L.Bently, D.D.Sleator, R.E.Tarjan, and V.K.Wei. A locally adaptive data compression algorithm. Communications of the ACM, Vol. 29, No. 4, April 1986, pp. 320-330

E.M.McCreight. A space economical suffix tree construction algorithm. Journal of the ACM, Val. 32, No. 2, April 1976, pp. 262-272.

U.Manber and E.W.Mayers, Suffix arrays: Anew method for on-line string searches. SIAM Journal on Computing, Vol. 22, No. 5, October 1993, pp. 935-948.

Смотри также раздел 2.6.3 "Сжатие данных с использованием преобразования Барроуза-Вилера",

Локальные сети (обзор)

4.1 Локальные сети (обзор)

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.1	Локальные сети (обзор)	1	1
4.1.1	Ethernet (IEEE 802.3)	1	1
4.1.2	IEEE 802.5 (Token Ring)	12	12
4.1.3	IEEE 802.4 (Маркерная шина)	3	22
4.1.4	Сети управления и сбора данных в реальном масштабе времени (CAN)	5	75
4.1.5	Локальные сети ArcNet	4	139
4.1.6	Сети FDDI	8	328
4.1.7	Параллельный сетевой интерфейс HIPPI	4	37
4.1.8	Сети IEEE 802.11	3	58
4.1.9	Сети DQDB (двойная шина с распределенной очередью)	3	29
4.1.10	Сети с многокаскадными соединениями	1	19
4.1.11	Сети 100Base-VG	1	4
4.1.12	Канальный протокол Fibre Channel	4	35
4.1.13	Коммутируемая мультимегабитная информационная служба SMDS	2	17

В этом разделе речь идет о физической среде локальных сетей.

Обзор протокола

3. Обзор протокола

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

PPP кадры
L2TP Информационные сообщения		L2TP Управляющие сообщения
L2TP Информационный канал (ненадежный)		L2TP Канал управления (надежный)
Транспортировка пакетов (UDP, FR, ATM, etc.)

Пары значений-атрибутов управляющих сообщений

4. Пары значений-атрибутов управляющих сообщений

4.1. Формат AVP

Каждая AVP кодируется следующим образом:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

rsvd

Длина

ID производителя

Тип атрибута

Значение атрибута

Продолжение поля значение атрибута до границы, заданной полем длина

Поле значения атрибута для AVP ACCM

Рисунок 17. Поле значения атрибута для AVP ACCM

Посланное ACCM и полученное ACCM имеют по 4 октета, перед которыми размещаются 2 октета зарезервированного количества. Значение посланного ACCM должно использоваться LAC для обработки пакетов, которые он отправляет через канал. Значение полученного ACCM должно использоваться LAC для обработки пакетов, которые он получает через канал. Значения по умолчанию, используемые LAC для обоих этих полей равны 0xFFFFFFFF. LAC должен учитывать значения этих полей, если только нет конфигурационной информации, которая указывает, что запрошенная маска должна быть модифицирована, чтобы разрешить операцию.

Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 16.

5. Протокольные операции

Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:

Установление управляющего канала для туннеля, и

Формирование сессии в соответствии с запросом входящего или исходящего вызова.

Туннель и соответствующий управляющий канал должны быть сформированы до инициализации входящего или исходящего вызовов. L2TP-сессия должна быть реализована до того, как L2TP сможет передавать PPP-кадры через туннель. В одном туннеле могут существовать несколько сессий между одними и теми же LAC и LNS.

Поле значения атрибута для AVP ID прокси Authen

Рисунок 15. Поле значения атрибута для AVP ID прокси Authen

ID представляет собой 2-октетное целое число без знака, старший октет которого должен быть равен нулю.

AVP прокси Authen ID должна присутствовать для типов Proxy authen 2, 3 и 5. Для 2 и 5, поле ID содержит значение ID-байта переданное LAC клиенту в его приглашении (Challenge). Для 3 - это значение идентификатора Authenticate-Request. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0.

Отклик прокси Authen Response (ICCN)

AVP отклика прокси Authen, тип атрибута 33, специфицирует отклик аутентификации PPP, полученный LAC от PPP-партнера, когда используется прокси аутентификация. Отклик представляет собой строку октетов произвольной длины.

Эта AVP должна присутствовать для типов прокси authen 1, 2, 3 и 5. Поле отклика содержит отклик клиента на приглашение. Для типов прокси authen 2 и 5, это поле содержит значение отклика, полученное LAC. Для типов 1 или 3, оно несет в себе открытый текст пароля, полученного LAC от клиента. В случае паролей с открытым текстом рекомендуется AVP-сокрытие.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина отклика.

4.4.6. AVP статуса вызова

Ошибки вызова (WEN)

AVP ошибок вызова, тип атрибута 34, используется LAC для посылки LNS информации об ошибке. Поле значения атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Зарезервировано

Ошибка CRC (H)

Ошибка CRC (L)

Ошибка в формате кадра (H)

Ошибка в формате кадра (L)

Аппаратное переполнение (H)

Аппаратное переполнение (L)

Переполнение буфера (H)

Переполнение буфера (L)

Ошибка таймаута (H)

Ошибка таймаута (L)

Ошибка выравнивания (H)

Ошибка выравнивания (L)

Рисунок 11. Поле значения атрибута

Рисунок 11. Поле значения атрибута для AVP кода причины Q.931

В качестве кода причины присылается код Q.931, а в качестве сообщения причины – сообщение Q.931 (например, DISCONNECT), ассоциированное с кодом причины. Оба кода присылаются в их исходных кодировках ITU [DSS1]. Дополнительный ASCI-текст сообщения-рекомендации может быть включен (присутствие определяется с помощью кода длины AVP) для дальнейшего уточнения причины отсоединения.

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 9, плюс размер сообщения Advisory.

ID, присвоенное сессии (CDN, ICRP, ICRQ, OCRP, OCRQ)

AVP ID, присвоенного сессии, тип атрибута 14, содержит ID, присвоенное сессии отправителем сообщения. ID, присвоенное сессии, представляет собой 2-октетное целое, ненулевое число без знака.

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

В управляющем сообщении CDN, используется первое AVP ID-сессии, полученное партнером, позволяя партнеру идентифицировать соответствующий туннель, даже если CDN послано до получения ID, присвоенное сессии.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8.

Порядковый номер вызова (ICRQ, OCRQ)

AVP порядкового номера вызова, тип атрибута 15, несет в себе идентификатор, присвоенный данному вызову LAC или LNS. Порядковый номер вызова представляет собой 32-битовый код.

Порядковый номер вызова предназначен для удобного административного указателя для обоих концов туннеля, когда необходимо проанализировать причину отказа.
Порядковые номера вызова должны быть монотонно возрастающими числами, которые должны быть уникальными для достаточно большого периода времени для всех соединенных LNS и LAC.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Максимальный BPS (OCRQ)

AVP максимального BPS, тип атрибута 16, характеризует минимальную приемлемую скорость передачи канала для данного вызова.

Максимальный BPS представляет собой 32-битовый код, характеризующий скорость передачи в битах в секунду.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Максимальный BPS (OCRQ)

AVP максимального BPS, тип атрибута 17, характеризует максимальную приемлемую скорость канала для данного вызова.

Максимальный BPS представляет собой 32-битный код, характеризующий скорость передачи в битах в секунду.

Эта AVP может быть скрытым (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) этого AVP равна 10.

Тип носителя (ICRQ, OCRQ)

AVP типа носителя, тип атрибута 18, характеризует тип носителя для входящего или исходящего вызовов. Поле значения атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Зарезервировано для будущих определений типа несущей среды	A	D

Поле значения атрибута для AVP ошибок вызова

Рисунок 16. Поле значения атрибута для AVP ошибок вызова

Определены следующие поля:

Зарезервировано	Не используется, должно равняться нулю 0
Ошибки CRC	Число PPP-кадров, полученных с CRC-ошибками с момента реализации вызова
Ошибки формата кадров	Число полученных PPP-пакетов с неверным форматом
Аппаратное переполнение	Число переполнений аппаратного буфера с момента реализации вызова
Число переполнений буфера	Число зарегистрированных переполнений буфера с момента реализации вызова
Число ошибок таймаутов	Число таймаутов с момента реализации вызова
Ошибки выравнивания	Число ошибок выравнивания с момента реализации вызова

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 32.

ACCM (SLI)

AVP ACCM, тип атрибута 35, используется LNS, чтобы проинформировать LAC о ACCM, согласуемом LNS с PPP-партнером. Поле значения атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Зарезервировано

Послать ACCM (H)

Послать ACCM (L)

Получить ACCM (H)

Получить ACCM (L)

Поле значения атрибута для AVP скорости соединения Rx

Рисунок 14. Поле значения атрибута для AVP скорости соединения Rx

BPS имеет 4 октета, характеризующие скорость обмена в битах в секунду. Присутствие этой AVP означает, что быстродействие канала может быть асимметричным с учетом скорости передачи, заданной в AVP скорости соединения Rx.

Эта AVP может быть скрытой (бит H может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10.

ID физического канала (ICRQ, OCRP)

AVP ID физического канала, тип атрибута 25, представляет код физического канала, присвоенный ему производителем, и используемый при вызове. ID физического канала имеет 4 октета и служит только для целей регистрации.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 10.

ID частной группы (ICCN)

AVP ID частной группы, тип атрибута 37, используется LAC для индикации того, что этот вызов ассоциируется с определенной группой клиентов. ID частной группы представляет собой строку октетов произвольной длины.

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

ID частной группы представляет собой строку, соответствующую таблице в LNS, которая определяет конкретные характеристики выбранной группы. LAC может определить ID частной группы из отклика RADIUS, локальной конфигурации, или некоторых других источников.

Эта AVP может быть скрытой (H-бит может быть 1 или 0). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина ID частной группы.

Необходима нумерация (Sequencing Required (ICCN, OCCN))

AVP Sequencing Required, тип атрибута 39, сообщает LNS, что порядковые номера должны всегда присутствовать в информационном канале. Эта AVP не имеет поля значения атрибута.

Эта AVP не должна быть скрытой (H-бит должен быть 0). M-бит этой AVP должен быть равен 1. Длина этой AVP равна 6.

4.4.5. AVP прокси LCP и аутентификации

LAC может откликнуться на вызов и согласовать LCP с удаленной системой, возможно для того чтобы установить идентичность системы. В этом случае, эти AVP могут быть включены для индикации свойств канала, которые запросила удаленная система в исходном состоянии, свойства, согласованные удаленной системой и LAC после согласования, а также аутентификационная информация PPP, полученная LAC. Эта информация может быть использована, чтобы инициировать PPP LCP и аутентификационные системы в LNS, позволяя PPP продолжить работу без повторного согласования параметров с LCP.

LCP CONFREQ, полученный в исходном состоянии (ICCN)

В AVP, полученного в исходном состоянии LCP CONFREQ, тип атрибута 26, предоставляет LNS исходное сообщение CONFREQ, полученное LAC от партнера PPP.

LCP CONFREQ является копией тела полученного исходного CONFREQ, начиная с первой опции тела сообщения LCP. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

Последний посланный LCP CONFREQ (ICCN)

В AVP последнего посланного LCP CONFREQ, тип атрибута 27, предоставляет LNS последнего CONFREQ, посланного LAC партнеру PPP.

LCP CONFREQ является копией тела финального CONFREQ, посланного клиенту с целью завершения LCP-согласования, начиная с первой опции тела LCP-сообщения. Длина поля значения атрибута LCP CONFREQ имеет произвольную длину. Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

Последний полученный LCP CONFREQ (ICCN)

AVP последнего полученного LCP CONFREQ, тип атрибута 28, предоставляет LNS последнего CONFREQ, полученного концентратором LAC от PPP-партнера.

LCP CONFREQ является копией тела последнего CONFREQ, полученного от клиента с целью завершения процедуры согласования LCP, начиная с первой опции тела LCP-сообщения.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина CONFREQ.

Тип прокси Authen (ICCN)

AVP типа прокси Authen, тип атрибута 29, определяет, должна ли использоваться прокси аутентификация. Тип Authen представляет собой 2-октетное целое число без знака.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 8. Определенные значения типа Authen:

0 - Зарезервировано

1 – Текстовой обмен имя пользователя/пароль

2 - PPP CHAP

3 - PPP PAP

4 – Никакой аутентификации

5 - Microsoft CHAP версия 1 (MSCHAPv1)

Эта AVP должна присутствовать, если должна использоваться прокси аутентификация. Если она отсутствует, тогда предполагается, что этот партнер не может выполнить прокси аутентификацию, необходимую для повторного запуска фазы аутентификации в LNS, если клиент уже вошел в эту фазу с LAC (который может быть определен AVP Proxy LCP, если имеется). Далее описаны соответствующие AVP для каждого типа аутентификации.

Имя прокси Authen (ICCN)

AVP имени прокси Authen, тип атрибута 30, специфицирует имя аутентифицируемого клиента при использовании прокси аутентификации.

Имя Authen является строкой октетов произвольной длины. Оно содержит имя, специфицированное в отклике аутентификации клиента.

Эта AVP должна присутствовать в сообщениях, содержащих AVP типа Proxy Authen с типом Authen 1, 2, 3 или 5. Может быть, желательно применить AVP-сокрытие для защиты имени, представленного открытым текстом. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 6 плюс длина имени.

Приглашение прокси Authen (ICCN)

AVP приглашения прокси Authen, тип атрибута 31, специфицирует приглашение, посланное LAC партнеру PPP при использовании прокси аутентификации. Приглашение представляет собой строку из одного или более октетов.

Эта AVP должна присутствовать для типов прокси Authen 2 и 5.Поле приглашения содержит приглашение CHAP, предлагаемое LAC клиенту.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6, плюс длина приглашения.

ID прокси Authen (ICCN)

AVP ID прокси Authen, тип атрибута 32, специфицирует код ID PPP-аутентификации, которая реализуется между LAC и PPP-партнером, когда используется прокси аутентификация. Поле значения атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Зарезервировано	ID

Поле значения атрибута для AVP типа кадрового обмена

Рисунок 13. Поле значения атрибута для AVP типа кадрового обмена

Тип кадрового обмена представляет собой 32-битовую маску, которая указывает тип кадрового обмена PPP, запрошенный для OCRQ, или тип кадрового обмена PPP, согласованный для OCCN или ICCN. Тип кадрового обмена может быть использован как указание PPP на LNS, какую из канальных опций использовать для согласования с LCP [RFC1662].

Бит A указывает на асинхронный обмен кадрами. Бит S указывает на синхронный обмен кадрами. Для OCRQ могут быть установлены оба бита, что будет означать допустимость обоих типов кадрового обмена.

Биты в поле значение этой AVP должны устанавливаться только LNS для OCRQ, если они были установлены в AVP возможностей кадрового обмена, полученной от LAC в процессе установления управляющего соединения. Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Вызванный номер (Called Number (ICRQ, OCRQ))

AVP вызванного номера, тип атрибута 21, характеризует телефонный номер, куда посылается вызов для OCRQ.

Вызванный номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера.

Вызывающий номер (Calling Number (ICRQ))

AVP вызывающего номера, тип атрибута 22, содержит телефонный номер входящего вызова.

Вызывающий номер представляет собой ASCII-строку произвольной длины. Может быть необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

Субадрес (ICRQ, OCRQ)

AVP субадреса, тип атрибута 23, несет в себе дополнительную информацию по вызову.

Субадрес является ASCII-строкой. Может быть, необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина субадреса.

Скорость канала (Tx) (Connect Speed (ICCN, OCCN))

AVP скорости канала (Tx) BPS, тип атрибута 24, характеризует быстродействие устройства, выбранного для попытки установления соединения. Скорость канала (Tx) BPS содержит 4 октета и характеризует скорость обмена в битах в секунду.

Когда присутствует опционная AVP скорости соединения Rx, значение этой AVP представляет быстродействие канала с точки зрения LAC (например, скорость передачи данных, передаваемых от LAC в удаленную систему). Когда опционная AVP скорости соединения Rx отсутствует, быстродействие канала между удаленной системой и LAC предполагается симметричным и представляется одной величиной этой AVP.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Скорость соединения Rx (Connect Speed (ICCN, OCCN))

AVP скорости соединения Rx, тип атрибута 38, представляет скорость канала с точки зрения LAC (например, информация, передаваемая от удаленной системы в LAC). Поле значения атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
BPS (H)	BPS (L)

Поле значения атрибута для AVP типа носителя

Рисунок 12. Поле значения атрибута для AVP типа носителя

Тип носителя представляет собой 32-битовую маску, которая характеризует возможности несущей среды для вызова (ICRQ) или требования к среде для данного вызова (OCRQ). Если бит A=1, то вызов относится к аналоговому каналу. Если бит D=1, то вызов относится к цифровому каналу. Могут быть установлены оба бита, что может означать, что тип канала не определен, или допустима работа, как с аналоговым, так и цифровым каналами.

Биты в поле значение данной AVP должны устанавливаться LNS для OCRQ, если они были установлены в AVP возможностей носителя, полученной от LAC в период установления управляющего соединения.

Можно не устанавливать ни A, ни D-биты в ICRQ. Такая установка может означать, что вызов не был получен по физическому каналу (например, если LAC и PPP находятся в той же подсистеме).

Эта AVP может быть скрыта (H-бит может быть 0 или 1). M-бит этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 10.

Тип кадрового обмена (ICCN, OCCN, OCRQ)

AVP типа кадрового обмена, тип атрибута 19, характеризует тип кадров для входящих и исходящих вызовов. Поле значения

атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Зарезервировано для будущих определений типа кадрового обмена

Поле значения атрибута для AVP управления контрольным соединением

Рисунок 8. Поле значения атрибута для AVP управления контрольным соединением

Поле Ver характеризуется целым числом без знака длиной в один октет и содержит код 1. Поле Rev характеризуется целым числом без знака длиной в один октет и содержит код 0. Так характеризуется версия протокола L2TP 1, и модификация версии 0. Заметим, что это не тот же код версии, что включается в заголовок каждого сообщения.

Эта AVP не должна быть скрытой (бит H должен быть равен 0). Бит M для данной AVP должен быть равен 1. Длина этой AVP равна 8.

Возможность работы с кадрами (SCCRP, SCCRQ)

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

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Зарезервировано для будущих определений типа кадрового обмена	A	S

Поле значения атрибута для AVP возможности работы с кадрами

Рисунок 9. Поле значения атрибута для AVP возможности работы с кадрами

Поле значения атрибута представляет собой 32-битовую маску, с двумя определенными битами. Если бит A=1, поддерживается асинхронный обмен кадрами. Если бит S=1, поддерживается синхронный обмен кадрами.

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

Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этого AVP должен быть равен 1. Длина (до сокрытия) равна 10.

Возможности носителя (SCCRP, SCCRQ)

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

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Зарезервировано для будущих определений типа несущей среды	A	D

Рисунок 10. Поле значения атрибута для AVP возможности носителя

Это 32-битная маска, с двумя определенными битами. Если бит A =1, поддерживается аналоговый доступ. Если бит D =1, поддерживается цифровой доступ.

LNS не должен запрашивать исходящих вызовов, специфицирующих значение в AVP типа носителя для приборов, неуказанных в AVP типа носителя, полученных от LAC при установлении управляющего соединения. Такая попытка приведет к тому, что вызов будет отвергнут. Эти AVP должны присутствовать, если отправитель может осуществлять исходящие вызовы, когда это требуется.

Заметим, что LNS, который не может работать как LAC, а также не поддерживает оборудование для обработки входящих и исходящих вызовов, должен установить биты A и D этого AVP равными 0, или не должен вообще посылать AVP. LNS, который может работать в качестве LAC, и направлять исходящие вызовы, должен устанавливать биты A или D так, как это нужно. Присутствие этого сообщения не гарантирует того, что данный исходящий вызов будет направлен отправителем, если это потребуется, хотя такая возможность и существует.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) равна 10.

Арбитр конфликта (Tie Breaker (SCCRQ))

AVP арбитра конфликта, тип атрибута - 5, указывает, что отправитель желает иметь один туннель между заданной парой LAC-LNS.

Значение Tie Breaker характеризуется 8-октетным кодом, который используется для выбора одного туннеля, когда LAC и LNS требуют формирования туннеля одновременно. Получатель SCCRQ должен проверить, был ли послано партнеру SCCRQ и, если это так, должен сравнить свое значение Tie Breaker с полученным. Более низкое значение "wins" и "loser" должно вызвать молчаливую ликвидацию туннеля. В случае, когда код арбитра присутствует на обеих сторонах и значения равны, обе стороны должны ликвидировать туннели. Если получен tie breaker, а невыполненный просроченный SCCRQ не имеет значения tie breaker, инициатор, который включает AVP Tie Breaker "выигрывает".

Если ни одна из сторон не посылает Tie Breaker, тогда открываются два туннеля.

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этого AVP должен быть равен 0. Длина этой AVP равна 14.

Фирменная версия (Firmware Revision) (SCCRP, SCCRQ)

Фирменная версия AVP, тип атрибута 6, указывает на фирменную версию прибора, пославшего сообщение.

Поле фирменная версия имеет 2 октета и представляется целым числом без знака, закодированным в формате, который определяется фирмой.

Для приборов, которые не имеют кода фирменной версии (универсальные ЭВМ, где, например, работают программные модули L2TP), вместо этого может быть сообщена модификация программных модулей L2TP.

Эта AVP может быть скрыта (H-бит может быть равен 0 или 1). M-бит для этой AVP должен быть равен 0. Длина (до сокрытия) равна 8.

Имя ЭВМ (SCCRP, SCCRQ)

AVP имени ЭВМ, тип атрибута 7, указывает на имя ЭВМ, реализующей функцию LAC или LNS.

Имя ЭВМ имеет переменную длину, но должно иметь, по крайней мере, один октет. Это имя должно быть максимально уникальным; для ЭВМ, участвующих в DNS [RFC1034], следует выбирать полное имя домена.

Эта AVP не должна быть скрыта (H-бит должен быть 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 6 плюс длина имени ЭВМ.

Имя производителя (SCCRP, SCCRQ)

AVP имени производителя, тип атрибута 8, содержит специфическую для производителя строку, которая характеризует тип используемого LAC или LNS.

Имя производителя представляет собой строку октетов произвольной длины. Для обеспечения читаемости текст этой AVP должен быть представлен с помощью символьного набора UTF-8 на языке, выбранном по умолчанию [RFC2277].

Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для данной AVP должен быть равен 0. Длина (до сокрытия) этой AVP равна 6 плюс длина имени производителя.

ID, присвоенное туннелю (SCCRP, SCCRQ, StopCCN)

AVP ID, присвоенного туннелю, тип атрибута 9, несет в себе ID, присвоенное туннелю отправителем.

ID, присвоенное туннелю, содержит в себе 2-октетное целое неравное нулю число без знака.

AVP ID, присвоенное туннелю, определяет код, используемый при мультиплексировании и демультиплексировании в случае работы с несколькими туннелями между LNS и LAC. Партнер L2TP должен помещать этот код в поле заголовка ID-туннеля всех управляющих и информационных сообщений, пересылаемых через туннель. Пока от партнера не получена AVP с присвоенным ID-туннеля, управляющие сообщения должны посылаться этому партнеру со значением ID-туннеля = 0.

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

Эта AVP может быть скрытой (H-бит может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 8.

Размер приемного окна (Receive Window Size (SCCRQ, SCCRP))

Размер приемного окна AVP, тип атрибута 10, специфицирует размер приемного окна, которое предлагает удаленный партнер. Размер окна характеризуется 2-октетным целым числом без знака.

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

Эта AVP не должна быть скрытой (H-бит должен быть равен 0). M-бит для этой AVP должен быть равен 1. Длина этой AVP равна 8.

Приглашение (Challenge (SCCRP, SCCRQ))

AVP приглашения, тип атрибута 11, указывает, что отправивший его партнер хочет аутентифицировать концы туннеля, используя CHAP-стиль аутентификационного механизма. Вызов содержит один или более октетов произвольной информации.

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина приглашения (challenge).

Отклик на приглашение (Challenge Response (SCCCN, SCCRP))

AVP отклика, тип атрибута 13, направляет ответ на полученное сообщение.

Поле отклик содержит 16 октетов, соответствуя CHAP-стилю [RFC1994] отклика на вызов.

Эта AVP должна присутствовать в SCCRP или SCCCN, если приглашение было получено в предыдущем SCCRQ или SCCRP. Для целей вычисления значения ID в CHAP-отклике используется код типа сообщения AVP для этого кадра (например, 2 для SCCRP, и 3 для SCCCN).

Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 22.

4.4.4. AVP управления вызовом

Q.931 код причины (CDN)

AVP, тип атрибута 12, используется, чтобы предоставить дополнительную информацию в случае непреднамеренного разрыва соединения. Поле значения атрибута для этого AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Код причины	Сообщение причины	Сообщение-рекомендация

PPP-туннелирование

Рисунок 18. PPP-туннелирование

5.1. Установление контрольного соединения

Управляющее соединение является первичным, которое должно быть реализовано между LAC и LNS, прежде чем запускать сессию. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т.д.. Для установления управляющего соединения осуществляется обмен тремя сообщениями. Типичным является ниже приведенный обмен:

LAC или LNS LAC или LNS

SCCRQ ->

SCCCN ->

Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.

5.1.1. Аутентификация туннеля

L2TP включает в себя простую, опционную, CHAP-подобную [RFC1994] систему аутентификации туннеля в процессе установления \управляющего соединения. Если LAC или LNS хочет идентифицировать партнера, с которым контактирует или контактировал посредством AVP приглашения, включенного в SCCRQ или SCCRP-сообщения. Если в SCCRQ или SCCRP получена AVP приглашения, AVP отклика приглашения должна быть послана в следующем SCCRP или SCCCN, соответственно. Если ожидаемый отклик партнера не соответствует полученному, установление туннеля должно быть запрещено.

При участии в аутентификации туннеля LAC и LNS должны обладать общим секретным кодом. Это тот же секретный код, который использовался для AVP-сокрытия (смотри раздел 4.3).

5.2. Установление сессии

После успешного установления управляющего соединения, могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.

5.2.1. Установление входящего вызова

Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен:

LAC LNS

(Обнаружен вызов)

ICRQ ->

ICCN ->

Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.

5.2.2. Установление исходящего вызова

Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен:

LAC LNS

OCRP ->

(Выполнить операцию вызова)

OCCN ->

Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.

5.3. Переадресация кадров PPP

Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков, и т.д., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет, и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP.

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

Значение 0 для ID-сессии и ID-туннеля является зарезервированным и не должно использоваться в качестве ID-сессии или ID-туннеля. Для случаев, когда ID-сессии еще не присвоен партнером (т.e., в процессе установления новой сессии или туннеля), поле ID-сессии должно содержать 0, а для идентификации сессии должна использоваться AVP ID-сессии сообщения. Аналогично, для случаев, когда ID-туннеля еще не присвоен партнером, ID-туннеля должен быть присвоен 0, а для идентификации туннеля должна использоваться AVP ID-туннеля.

5.4. Использование порядковых номеров в канале данных

Порядковые номера определены в заголовке L2TP для управляющих сообщений и опционно для информационных (смотри раздел 3.1). Они используются для организации надежной транспортировки управляющих сообщений (смотри раздел 5.8) и опционно информационных сообщений.

Каждый партнер поддерживает отдельную нумерацию для управляющего соединения и для каждой информационной сессии в пределах туннеля.

В отличие от канала управления L2TP, информационный канал L2TP не использует нумерацию сообщений для повторной пересылки. Скорее информационные сообщения могут использовать порядковые номера для детектирования потерь пакетов и/или восстановления исходной последовательности пакетов, которые могут быть перемешаны при транспортировке. LAC может потребовать, чтобы порядковые номера присутствовали в информационных сообщениях, посредством AVP необходимого упорядочения (смотри раздел 4.4.6). Если эта AVP присутствует при установлении сессии, порядковые номера должны присутствовать всегда. Если эта AVP отсутствует, упорядочивание сообщений находится под управлением LNS. Сервер LNS управляет разрешением и запрещением использования порядковых номеров путем посылки информационных сообщений с или без порядковых номеров на протяжении всей сессии. Таким образом, если LAC получает информационное сообщение без порядкового номера, он должен прекратить посылку сообщений с порядковыми номерами. Если LAC получает информационное сообщение с порядковым номером, он должен начать посылку информационных сообщений с порядковыми номерами. Если LNS разрешает нумерацию сообщений после предыдущего запрещения в ходе сессии, порядковые номера устанавливаются в соответствии с состоянием их последнего применения.

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

5.5. Keepalive (Hello)

Механизм keepalive используется L2TP, для того чтобы разделять простои туннеля от длительных периодов отсутствия управления или информационной активности в туннеле. Это выполняется путем введения управляющих сообщений Hello (смотри раздел 6.5) после специфицированного периода времени, истекшего с момента последнего получения управляющего сообщения через туннель. Как для любого другого управляющего сообщения, при недоставке сообщения Hello туннель объявляется нерабочим, и система возвращается в исходное состояние. Механизм перевода транспортной среды в исходное состояние путем введения сообщений Hello гарантирует, что разрыв соединения между LNS и LAC будет детектирован на обоих концах туннеля.

5.6. Прерывание сессии

Прерывание сессии может быть инициировано LAC или LNS и выполняется путем посылки управляющего сообщения CDN. После того как последняя сессия прервана, управляющее соединение может быть также разорвано. Ниже приводится типовой обмен управляющими сообщениями:

LAC или LNS LAC или LNS

CDN ->

(Clean up)


	(Clean up)

5.7. Разрыв контрольного соединения

Разрыв контрольного соединения может быть инициирован LAC или LNS и выполняется путем посылки одного управляющего сообщения StopCCN. Получатель StopCCN должен послать ZLB ACK, чтобы подтвердить получение сообщения, и поддерживает состояние управляющего соединения на уровне достаточном для корректного приема StopCCN, а также повторения цикла, если ZLB ACK потеряно. Рекомендуемое время повторения цикла равно 31 секунде (смотри раздел 5.8). Ниже приводится типовой обмен управляющими сообщениями:

LAC или LNS LAC или LNS

StopCCN ->

(Clean up)


	(Wait)
	(Clean up)

Программа может ликвидировать туннель и все сессии туннеля путем посылки StopCCN. Таким образом, не нужно прерывать каждую сессию, если разорван туннель.

5.8. Надежная доставка управляющих сообщений

L2TP обеспечивает нижний уровень надежного транспорта для всех управляющих сообщений.

Поля Nr и Ns заголовка управляющего сообщения (смотри раздел 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не занимаются повторной пересылкой или упорядочением управляющих сообщений. Надежный управляющий канал обеспечивается за счет специального протокола, например, TCP, поддерживающего повторную пересылку управляющих сообщений и контроль перегрузки. Каждый партнер поддерживает независимую нумерацию сообщений для управляющего канала в туннеле.

Порядковые номера сообщений Ns начинаются с 0. Каждое последующее сообщение имеет номер на 1 больше, чем предыдущее. Номер по порядку, таким образом, является простым счетчиком, работающим по модулю 65536. Порядковый номер в заголовке полученного сообщения рассматривается меньше или равным последнему полученному числу, если его значение лежит в интервале между последним полученным кодом и предыдущими 32767 включительно. Например, если последний полученный номер был равен 15, тогда сообщения с порядковыми номерами 0 - 15, а также 32784 - 65535, будут рассматриваться как сообщение с меньшим или равным номером. Такое сообщение будет рассматриваться как дубликат уже полученного и не будет обрабатываться. Однако, для того чтобы гарантировать, что все сообщения подтверждены корректно (в частности в случае потери сообщения ZLB ACK), получение сообщения-дубликата должно быть подтверждено. Это подтверждение может быть реализовано косвенно, или непосредственно через ZLB ACK.

Все управляющие сообщения в пространстве номеров занимают одну нишу, за исключением подтверждения ZLB. Таким образом, Ns не инкрементируется после посылки сообщения ZLB.

Номер последнего полученного сообщения, Nr, используется для подтверждения сообщений, принятых L2TP-партнером. Этот код должен содержать порядковый номер сообщения, которые партнер ожидает получить следующим (например, последний Ns сообщения (non-ZLB) плюс 1, по модулю 65536). В то время как Nr в полученном ZLB используется для удаления сообщений из локальной очереди сообщений, ждущих imes повторной передачи в локальной очереди (смотри ниже), Nr следующего сообщения не должен обновляться при получении Ns ZLB.

Протокол надежной доставки принимающего партнера ответственен за проверку того, что управляющие сообщения доставлены на верхний уровень в правильном порядке и без дублирования. Сообщения, пребывающие в неверном порядке, могут быть занесены в очередь для последующей корректной доставки, когда пропущенные сообщения будут получены, или они могут быть выброшены, что вынудит партнера послать их повторно. Каждый туннель поддерживает очередь управляющих сообщений, которые нужно передать его партнеру. Сообщение в начале очереди посылается с заданным значением Ns, и хранится до тех пор, пока не придет от партнера управляющее сообщение, в котором поле Nr указывает на то, что данное сообщение получено. Если в течение определенного времени (рекомендуемое значение равно 1 секунде) отклика не получено, сообщение посылается повторно. Повторно посылаемое сообщение имеет то же значение Ns, но величина Nr должна быть сделана равной номеру очередного ожидаемого сообщения.

Каждая повторная посылка сообщения должна реализовываться по истечении задержки, величина которой возрастает экспоненциально от раза к разу. Таким образом, если первая повторная передача происходит спустя 1 секунду, следующая повторная передача может производиться по истечении 2 секунд, затем 4 секунд, и т.д.. Программная реализация может установить верхний предел на время между повторными пересылками сообщения. Этот предел должен быть не меньше 8 секунд. Если после нескольких повторных посылок, не зафиксировано никакого отклика от партнера, (рекомендуемое число попыток равно 5, но должно быть настраиваемым), туннель и все сессии должны быть аннулированы.

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

Механизм скользящего окна используется для передачи управляющих сообщений. Рассмотрим двух партнеров A & B. Предположим A задает размер приемного окна в сообщениях SCCRQ или SCCRP равным N. B при этом позволено иметь до N ожидающих подтверждения получения сообщений.

Когда N послано, нужно ждать подтверждения, которое сдвинет окно, прежде чем посылать новое управляющее сообщение. Программная реализация может поддерживать приемное окно с размером 1 (т.e., посылать AVP размера приемного окна со значением 1), но должно воспринимать от своего партнера окна с шириной до 4 (например, имеет возможность послать 4 сообщения, прежде чем остановиться и ожидать отклика). Значение 0 для AVP размера приемного окна является недопустимым.

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

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

6. Протокольная спецификация контрольного соединения

Следующие сообщения управляющего соединения используются для установления, ликвидации и поддержания L2TP-туннелей. Вся информация посылается в порядке, определенном для сети (старший октет первый). Любые "резервные" или "пустые" поля для обеспечения протокольной масштабируемости должны содержать 0.

6.1. Start-Control-Connection-Request (SCCRQ)

Start-Control-Connection-Request (SCCRQ) является управляющим сообщением, используемым для инициализации туннеля между LNS и LAC. Оно посылается LAC или LNS в процессе установления туннеля. Следующие AVP должны присутствовать в SCCRQ:

AVP типа сообщения (Message Type AVP)

Версия протокола (Protocol Version)

Имя ЭВМ (Host Name)

Возможности кадрового обмена (Framing Capabilities)

Присвоенный туннелю ID (Assigned Tunnel ID)

Следующие AVP могут присутствовать в SCCRQ:

Возможности канала (Bearer Capabilities)

Размер премного окна (Receive Window Size)

Приглашение (Challenge)

Арбитр конфликта (Tie Breaker)

Фирменная версия (Firmware Revision)

Имя производителя (Vendor Name)

6.2. Start-Control-Connection-Reply (SCCRP)

Start-Control-Connection-Reply (SCCRP) является управляющим сообщением, посланным в ответ на сообщение SCCRQ. SCCRP используется для индикации того, что SCCRQ было принято и установление туннеля должно быть продолжено. Следующие AVP должны присутствовать в SCCRP:

Тип сообщения (Message Type)

Версия протокола (Protocol Version)

Framing Capabilities

Имя ЭВМ (Host Name)

Присвоенный туннелю ID (Assigned Tunnel ID)

Следующие AVP могут присутствовать в SCCRP:

Возможности несущего канала (Bearer Capabilities)

Фирменная версия (Firmware Revision)

Имя производителя (Vendor Name)

Размер приемного окна (Receive Window Size)

Приглашение (Challenge)

Отклик на приглашение (Challenge Response)

6.3. Start-Control-Connection-Connected (SCCCN)

Start-Control-Connection-Connected (SCCCN) является управляющим сообщением, посылаемым в ответ на SCCRP. SCCCN завершает процесс установления туннеля.

Следующее AVP должно присутствовать в SCCCN:	Message Type
Следующее AVP может присутствовать в SCCCN:	Challenge Response

6.4. Stop-Control-Connection-Notification (StopCCN)

Stop-Control-Connection-Notification (StopCCN) является управляющим сообщением, посылаемым LAC или LNS для информирования своего партнера о том, что туннель закрывается (shutdown) и управляющий канал должен быть разорван. Кроме того, все активные сессии закрываются (без посылки каких-либо управляющих сообщений). Причина для отправки этого запроса указывается в AVP кода результата. Явно отклик на это сообщение не посылается, используется отклик ACK, который используется для обеспечения надежной связи для управляющего соединения транспортного уровня

Следующие AVP должны присутствовать в StopCCN:

Тип сообщения (Message Type)

Присвоенный туннелю ID (Assigned Tunnel ID)

Результирующий код (Result Code)

6.6. Запрос входящего вызова ICRQ (Incoming-Call-Request)

Incoming-Call-Request (ICRQ) является управляющим сообщением, посылаемым LAC к LNS, когда зарегистрирован входящий вызов. Это первое из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.

ICRQ используется для индикации того, что для данного вызова должна быть установлена сессия между LAC и LNS, и предоставляет LNS параметры сессии. LAC может отложить ответ на вызов, до тех пор пока он не получит ICRP от LNS, указывающий, что должна быть запущена сессия. Этот механизм позволяет LNS получить достаточно информации о вызове, прежде чем будет определено, следует ли на него отвечать. В качестве альтернативы LAC может ответить на вызов, согласовать аутентификацию LCP и PPP, и использовать информацию, полученную для выбора LNS. В этом случае, к моменту получения сообщения ICRP на вызов уже получен ответ; в этом случае LAC просто разыгрывает шаги "call indication" и "call answer". Следующие AVP должны присутствовать в ICRQ:

Тип сообщения

ID, Присвоенный сессии (Assigned Session ID)

Call Serial Number

Следующие AVP могут присутствовать в ICRQ:

Тип носителя (Bearer Type)

ID физического канала (Physical Channel ID)

Вызывающий номер (Calling Number)

Вызванный номер (Called Number)

Субадрес (Sub-Address)

6.7. Отклик входящего вызова ICRP (Incoming-Call-Reply)

Incoming-Call-Reply (ICRP) является управляющим сообщением, посылаемым LNS к LAC в ответ на полученное сообщение ICRQ. Он является вторым из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.

ICRP используется для индикации того, что ICRQ успешен, и для LAC, чтобы ответить на вызов, если это еще не было сделано. Оно позволяет также LNS индицировать необходимые параметры для L2TP-сессии. Следующие AVP должны присутствовать в ICRP:

Тип сообщения (Message Type)

ID, присвоенный сессии (Assigned Session ID)

6.8. Incoming-Call-Connected (ICCN)

Incoming-Call-Connected (ICCN) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение ICRP.

Оно является третьим сообщением из трех сообщений обмена, используемых для установления сессий в пределах L2TP-туннеля.

ICCN используется для индикации того, что ICRP принято, на вызов получен ответ, а L2TP-сессия должна перейти в состояние “установлена”. Оно также предоставляет дополнительную информацию LNS о параметрах, используемых для вызова, на который получен ответ (параметры, которые не всегда быть доступны в момент посылки ICRQ).

Следующие AVP должны присутствовать в ICCN:

Тип сообщения (Message Type)

Скорость обмена в канале ((Tx) Connect Speed)

Тип кадрового обмена (Framing Type)

Следующие AVP могут присутствовать в ICCN:

Initial Received LCP CONFREQ

Последнее посланное LCP CONFREQ

Последнее полученное LCP CONFREQ

Тип Proxy Authen

Имя Proxy Authen

Приглашение Proxy Authen

Прокси Authen ID

Отклик прокси Authen

ID частной группы

Скорость обмена соединения (Rx Connect Speed)

Необходима нумерация (Sequencing Required)

6.9. Запрос исходящего вызова OCRQ (Outgoing-Call-Request)

Outgoing-Call-Request (OCRQ) является управляющим сообщением, посылаемым от LNS к LAC для индикации того, что необходимо осуществить исходящий вызов LAC. Оно является первым сообщением из трех, которые используются для установления сессии в пределах L2TP-туннеля.

OCRQ используется для индикации того, что сессия для данного вызова между LNS и LAC установлена и предоставляет LAC параметры L2TP-сессии и вызова.

LNS должен получить от LAC AVP Bearer Capabilities (возможностей носителя) на фазе установления туннеля, для того чтобы послать LAC исходящий вызов. Следующие AVP должны присутствовать в OCRQ:

Тип сообщения (Message Type)

ID, присвоенное сессии (Assigned Session ID)

Call Serial Number

Минимальный BPS

Максимальный BPS

Тип несущего канала (Bearer Type)

Тип кадрового обмена (Framing Type)

Телефонный номер адресата (Called Number)

Следующие AVP могут присутствовать в OCRQ:

Sub-Address

6.10. Отклик исходящего вызова OCRP (Outgoing-Call-Reply)

Сообщение Outgoing-Call-Reply (OCRP) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение OCRQ.

Оно является вторым из трех сообщений, которые используются при установлении сессии в L2TP-туннеле. OCRP используется для индикации того, что LAC может попытаться послать исходящий вызов и вернуть определенные параметры, относящиеся к попытке вызова. Следующие AVP должны присутствовать в OCRP:

Тип сообщения (Message Type)

Assigned Session ID

Следующие AVP могут присутствовать в OCRP:

Physical Channel ID

6.11. Outgoing-Call-Connected (OCCN)

Сообщение Outgoing-Call-Connected (OCCN) является управляющим сообщением, посылаемым от LAC к LNS, следом за OCRP, и после того как исходящий вызов завершен. Это завершающее сообщение из трех, используемых при установлении сессии в пределах L2TP-туннеля.

OCCN используется для индикации того, что результат запрошенного исходящего вызова положителен. Оно также предоставляет LNS информацию об определенных параметрах, полученных после реализации вызова. Следующие AVP должны присутствовать в OCCN:

Тип сообщения (Message Type)

Скорость обмена ((Tx) Connect Speed)

Тип кадрового обмена (Framing Type)

Следующие AVP могут присутствовать в OCCN:

Скорость обмена (Rx Connect Speed)

Необходима нумерация (Sequencing Required)

6.12. Call-Disconnect-Notify (CDN)

Сообщение Call-Disconnect-Notify (CDN) является L2TP управляющим сообщением, посылаемым LAC или LNS с целью запроса разрыва соединения для определенного вызова в пределах туннеля. Его целью является информирование партнера о рассоединении и причине разрыва соединения. Партнер должен освободить все ресурсы, и не посылать сообщений о причине данной операции.

Следующие AVP должны присутствовать в CDN:

Message Type

Код результата (Result Code)

Assigned Session ID

Следующие AVP могут присутствовать в CDN:

Код причины Q.931

6.13. WAN-Error-Notify (WEN)

Сообщение WAN-Error-Notify является L2TP управляющим сообщением, посылаемым от LAC к LNS для индикации условий ошибки WAN (условия, которые реализовались в интерфейсе, поддерживающим PPP). Счетчики в этом сообщении являются накопительными.

Это сообщение должно посылаться, только когда произошла ошибка, и не чаще чем раз в 60 секунд. Счетчики сбрасываются, когда реализуется новый вызов. Следующие AVP должны присутствовать в WEN:

Тип сообщения (Message Type)

Ошибки вызова (Call Errors)

6.14. Set-Link-Info (SLI)

Сообщение Set-Link-Info является управляющим сообщением L2TP, посланным от LNS к LAC для установления согласуемых опций PPP. Эти опции можно изменять в любое время на протяжении реализации вызова, таким образом, LAC должен быть способен обновлять свою собственную информацию вызова и поведение на протяжении активной PPP-сессии. Следующие AVP должны присутствовать в SLI:

Тип сообщения (Message Type)

ACCM

7. Машины состояний управляющего соединения

Управляющие сообщения, определенные в разделе 6 пересылаются в соответствии с таблицами состояний, описанными в данном разделе. Таблицы определены для входящих вызовов, исходящих вызовов, а также для инициации самого туннеля. Таблицы состояний не задают таймауты и поведение при повторной передаче, так как это определяется механизмами, рассмотренными в секции 5.8.

7.1. Протокольные операции контрольного соединения

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

Получение некорректного или неправильно сформатированного управляющего сообщения должно регистрироваться соответствующим образом, а управляющее соединение возвращается в исходное состояние, чтобы гарантировать восстановление заданного состояния. Управляющее соединение может затем перезапуститься инициатором операции.

Некорректное управляющее сообщение определяется как сообщение, которое содержит тип сообщения, помеченное как обязательное (смотри раздел 4.4.1) и неизвестное программе управляющее сообщение, которое получено в правильной последовательности (например, в ответ на SCCRQ послано SCCCN).

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

Управляющее сообщение с некорректным заголовком должно быть отброшено. Управляющее сообщение с некорректным AVP должно проверить M-бит для этого AVP, чтобы определить, является ли ошибка исправимой или нет.

Неверно сформатированное, но исправимое необязательное (M-бит равен нулю) AVP в управляющем сообщении должно рассматриваться, также как нераспознанное необязательное AVP. Таким образом, если получена AVP с неверным форматом и битом M=1, сессия или туннель должны быть разорваны с соответствующим кодом результата или ошибки. Если M-бит не равен 1, AVP должно игнорироваться (за исключением записи об ошибке в местном журнале).

Это не должно рассматриваться, как разрешение посылать неверно сформатированные AVP, а лишь как указание на то, как реагировать на неверно сформатированное сообщение в случае его получения. Невозможно перечислить все возможные ошибки в сообщениях и дать совет, как с ними обходиться. Примером исправимой неверно сформатированной AVP может быть случай, когда получена AVP скорости соединения Rx, атрибут 38, с полем длина 8, а не 10 и BPS с двумя, а не четырьмя октетами. Так как Rx Connect Speed не является обязательным, такое условие не может рассматриваться как катастрофическое. Как таковое, управляющее сообщение должно быть воспринято, как если бы AVP не было получено (за исключением записи в локальный журнал ошибок). В нескольких случаях в последующих таблицах, посылается протокольное сообщение, а затем случается "сброс". Заметим, что, несмотря на ликвидацию туннеля одним из партнеров, в течение определенного времени механизм надежной доставки должен быть сохранен (смотри раздел 5.8) вплоть до окончательного закрытия туннеля. Это позволяет сообщениям управления туннеля надежно доставляться партнеру.

7.2. Состояния контрольного соединения

Протокол управляющего соединения L2TP не отличим от LNS и LAC, но различен для отправителя и получателя. Партнером инициатором является тот, кто первым формирует туннель (в конфликтной ситуации, это победитель).

Так как LAC или LNS может быть инициатором, может произойти столкновение. Смотри Tie Breaker AVP в разделе 4.4.3, где описано разрешение такого конфликта.

7.2.1. Установление контрольного соединения

Состояние	Событие	Действие	Новое состояние
Idle	Local Open request	Послать SCCRQ	wait-ctl-reply
Idle	Получить SCCRQ, приемлемо	Послать SCCRP	wait-ctl-conn
idle	Получить SCCRQ, не приемлемо	Послать StopCCN, Clean up	idle
idle	Получить SCCRP	Послать StopCCN Clean up	idle
Idle	Получить SCCCN	Clean up	idle
wait-ctl-reply	Получить SCCRP, приемлемо	Послать SCCCN, Послать tunnel-open ожидающей сессии	established
wait-ctl-reply	Получить SCCRP, не приемлемо	Послать StopCCN, Clean up	idle
wait-ctl-reply	Получить SCCRQ, проигрыш tie-breaker	Clean up, Re-queue SCCRQ для состояния idle	idle
wait-ctl-reply	Получить SCCCN	Послать StopCCN Clean up	idle
wait-ctl-conn	Получить SCCCN, приемлемо	Послать tunnel-open ожидающей сессии	established
wait-ctl-conn	Получить SCCCN, не приемлемо	Послать StopCCN, Clean up	idle
wait-ctl-conn	Получить SCCRP, SCCRQ	Послать StopCCN, Clean up	idle
Established	Local Open request (новый вызов)	Послать tunnel-open ожидающей сессии	established
Еstablished	Административное закрытие туннеля	Послать StopCCN Clean up	idle
Established	Получить SCCRQ, SCCRP, SCCCN	Send StopCCN Clean up	idle
Idle wait-ctl-reply, wait-ctl-conn, established	Получить StopCCN	Clean up	idle

Состояниями, ассоциированными с LNS или LAC для установления управляющего соединения, являются:

Idle (пассивно)

Инициатор и получатель начинают функционирование из этого состояния. Инициатор посылает SCCRQ, в то время как получатель остается в пассивном состоянии вплоть до получения SCCRQ.

wait-ctl-reply (ожидание управляющего отклика)

Инициатор проверяет, не поступил ли запрос на установление еще одного соединения от того же самого партнера, и если это так, реагирует на столкновение, как это описано в разделе 5.8.

Когда получено SCCRP, оно проверяется на совместимость версии. Если версия отклика ниже версии посланного запроса, должна использоваться более старая (низшая) версия. Если версия отклика более ранняя, и она поддерживается, инициатор переходит в состояние “установлено”. Если версия более ранняя и не поддерживается, партнеру должно быть послано StopCCN, а инициатор переходит в исходное состояние и разрывает туннель.

wait-ctl-conn (ожидание управляющего соединения)

Состояние, когда ожидается SCCCN; после получения, проверяется отклик приглашения. Туннель оказывается установленным, или разорванным, если не прошла аутентификация.

Established (установлено)

Установленное соединение может быть аннулировано по местным причинам или в результате получения Stop-Control-Connection-Notification. В случае местного разрыва инициатор должен послать Stop-Control-Connection-Notification и ликвидировать туннель.

Если инициатор получает Stop-Control-Connection-Notification, он должен разорвать туннель.

7.3. Временные соображения

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

7.4. Входящие вызовы

Сообщение Incoming-Call-Request генерируется LAC, когда зарегистрирован входящий вызов (например, звонки в телефонной линии). LAC выбирает ID-сессии и порядковый номер и индицирует тип носителя вызова. Модемы должны всегда индицировать аналоговый тип вызова. Вызовы ISDN должны индицировать цифровой тип вызова, когда доступно цифровое обслуживание и используется настройка скорости обмена, и аналоговый, если применен цифровой модем. Вызывающий номер, вызываемый номер и субадрес могут быть включены в сообщение, если они доступны через телефонную сеть.

Раз LAC посылает Incoming-Call-Request, он ждет отклика от LNS, но необязательно отвечает на вызов из телефонной сети. LNS может решить не воспринять вызов если:

Нет ресурсов для поддержки новых сессий;

Поля вызывающего, вызываемого и субадреса не соответствуют авторизованному пользователю;

Сервис носителя не авторизован или не поддерживается.

Если LNS решает принять вызов, он откликается посылкой Incoming-Call-Reply. Когда LAC получает Incoming-Call-Reply, он пытается подключить вызов. Последнее сообщение о подключении от LAC к LNS указывает, что статус вызова для LAC и LNS должнен перейти в состояние “установлено”. Если вызов завершается до того, как LNS успел принять его, LAC посылает Disconnect-Notify, чтобы индицировать эту ситуацию.

Когда телефонный клиент вешает трубку, LAC посылает сообщение Call-Disconnect-Notify. Если LNS хочет аннулировать вызов, он посылает сообщение Call-Disconnect-Notify и ликвидирует свою сессию.

7.4.1. Состояния LAC входящих вызовов

Состояние	Событие	Действие	Новое состояние
Idle	Bearer Ring или Готов индицировать входящее соединение	Инициировать локальное открытие туннеля	wait-tunnel
Idle	Получить ICCN, ICRP, CDN	Clean up	idle
wait-tunnel	Разрыв канала или локальный запрос закрытия	Clean up	idle
wait-tunnel	tunnel-open	Послать ICRQ	wait-reply
wait-reply	Получить ICRP, приемлемо	Послать ICCN	established
wait-reply	Получить ICRP, Не приемлемо	Послать CDN, Clean up	idle
wait-reply	Получить ICRQ	Послать CDN Clean up	idle
wait-reply	Получить CDN ICCN	Clean up	idle
wait-reply	Локальный запрос закрытия или потеря несущей	Послать CDN, Clean up	idle
Established	Получить CDN	Clean up	idle
Established	Получить ICRQ, ICRP, ICCN	Послать CDN, Clean up	idle
Established	Потеря несущей или локальный запрос закрытия	Послать CDN, Clean up	idle

Состояниями, ассоциированными с LAC, для входящих вызовов являются:

idle

LAC детектирует входящий вызов на одном из своих интерфейсов. Обычно это означает, что по аналоговой линии получены звонки или ISDN TE зарегистрировало входное сообщение Q.931 SETUP. LAC инициализирует свою машину состояния, формирующую туннель, и переходит в состояние ожидания подтверждения существования туннеля.

wait-tunnel

В этом состоянии сессия ожидает открытия соединения или верификации того, что туннель уже открыт. Как только получено уведомление о том, что туннель открыт, может быть начат обмен управляющими сообщениями сессии. Первым таким сообщением будет Incoming-Call-Request.

wait-reply

LAC получает CDN-сообщение, указывающее, что LNS не хочет воспринимать вызов и переходит назад в состояние idle

(пассивен), или получает сообщение Incoming-Call-Reply, означающее, что вызов принят, LAC посылает сообщение Incoming-Call-Connected и переходит в состояние “установлен”.

established

Через туннель передаются данные. Вызов может быть аннулирован после:

Событие на подключенном интерфейсе: LAC посылает сообщение Call-Disconnect-Notify

Получение сообщения Call-Disconnect-Notify: LAC переходит в исходное состояние, аннулируя вызов.

Локальная причина: LAC посылает сообщение Call-Disconnect-Notify.

7.4.2. Состояния LNS входящих вызовов

Состояние	Событие	Действие	Новое состояние
Idle	Получение ICRQ, Приемлемо	Послать ICRP	wait-connect
idle	Получение ICRQ, Не приемлемо	Послать CDN, Clean up	idle
idle	Получение ICRP	Послать CDN Clean up	idle
Idle	Получение ICCN	Clean up	idle
wait-connect	Получение ICCN Приемлемо	Подготовиться для приема данных	established
wait-connect	Получение ICCN Не приемлемо	Послать CDN, Clean up	idle
wait-connect	Получение ICRQ, ICRP	Послать CDN Clean up	idle
idle, wait-connect, established	Получение CDN	Clean up	idle
wait-connect established	Локальный запрос закрытия	Послать CDN, Clean up	idle
established	Получение ICRQ, ICRP, ICCN	Послать CDN Clean up	idle

Состояниями, ассоциированными с LNS для входящих вызовов являются:

idle

Получено сообщение Incoming-Call-Request. Если запрос неприемлем, посылается Call-Disconnect-Notify LAC и LNS остается в состоянии idle. Если сообщение Incoming-Call-Request приемлемо, посылается Incoming-Call-Reply. Сессия переходит в состояние wait-connect.

wait-connect

Если сессия все еще подключена к LAC, он посылает сообщение Incoming-Call-Connected LNS, который затем переходит в состояние ”установлено”. LAC может послать Call-Disconnect-Notify для индикации того, что источник входящего запроса не может быть подключен. Это может произойти, например, если пользователь телефона случайно устанавливает в LAC стандартный голосовой режим, что приводит прерыванию диалога с модемом.

established

Сессия завершается при получении сообщения Call-Disconnect-Notify от LAC или путем посылки Call-Disconnect-Notify. Сброс системы в базовое состояние происходит на обеих сторонах вне зависимости от действий инициатора операции.

7.5. Исходящие вызовы

Исходящие вызовы инициируются LNS и заставляют LAC реализовать вызов. Для исходящих вызовов используется три сообщения: Outgoing-Call-Request, Outgoing-Call-Reply, и Outgoing-Call-Connected. LNS посылает Outgoing-Call-Request, специфицирующий телефонный номер партнера, субадрес и другие параметры. LAC должен реагировать на сообщение Outgoing-Call-Request откликом Outgoing-Call-Reply, так как LAC определяет, что имеется возможность реализовать вызов, который должен быть административно авторизован. Например, разрешено ли LNS осуществлять международные телефонные вызовы? Если для исходящего вызова осуществлено соединение, LAC посылает LNS сообщение Outgoing-Call-Connected, характеризующее окончательный результат попытки вызова.

7.5.1. Состояния LAC исходящих вызовов

Состояние	Событие	Действие	Новое состояние
Idle	Получение OCRQ, Приемлемо	Послать OCRP, Open bearer	wait-cs-answer
idle	Получение OCRQ, Не приемлемо	Послать CDN, Clean up	idle
idle	Получение OCRP	Послать CDN Clean up	idle
Idle	Получение OCCN, CDN	Clean up	idle
wait-cs-answer	Bearer answer, framing detected	Послать OCCN	established
wait-cs-answer	Bearer failure	Послать CDN, Clean up	idle
wait-cs-answer	Получение OCRQ, OCRP, OCCN	Послать CDN Clean up	idle
Established	Получение OCRQ, OCRP, OCCN	Послать CDN Clean up	idle
wait-cs-answer, established	Получение CDN	Clean up	idle
established	Потеря несущей, локальный запрос закрытия	Послать CDN, Clean up	idle

<

/p> Состояниями, ассоциированными с LAC, для исходящих вызовов являются:

idle

Если Outgoing-Call-Request получен с ошибкой, посылается отклик Call-Disconnect-Notify. В противном случае, выделяется физический канал и посылается Outgoing-Call-Reply. Производится исходящий вызов и LAC переходит в состояние wait-cs-answer.

wait-cs-answer

Если вызов не завершен или произошел таймаут ожидания завершения вызова, посылается Call-Disconnect-Notify с соответствующими кодами ошибки и происходит переход в состояние idle. Если устанавливается соединение с коммутацией каналов и зафиксирован обмен кадрами, посылается Outgoing-Call-Connected, отмечающий успешную реализацию вызова и LAC переходит в состояние “установлено”.

established

Если LAC получил Call-Disconnect-Notify, вызов должен быть аннулирован через соответствующий механизм и сессия закрыта. Если вызов аннулирован клиентом или интерфейсом, через который был осуществлен вызов, должно быть послано LNS сообщение Call-Disconnect-Notify. Отправитель сообщения Call-Disconnect-Notify переходит в состояние idle.

7.5.2. Состояние исходящего вызова LNS

Состояние	Событие	Действие	Новое состояние
Idle	Локальный запрос открытия	Инициировать локально tunnel-open	wait-tunnel
idle	Получение OCCN, OCRP, CDN	Clean up	idle
wait-tunnel	tunnel-open	Послать OCRQ	wait-reply
wait-reply	Получение OCRP, Приемлемо	никакого	wait-connect
wait-reply	Получение OCRP, Не приемлемо	Послать CDN Clean up	idle
wait-reply	Получение OCCN, OCRQ	Послать CDN Clean up	idle
wait-connect	Получение OCCN	none	established
wait-connect	Получение OCRQ, OCRP	Послать CDN Clean up	idle
Idle, wait-reply, wait-connect, established	Получение CDN,	Clean up	idle
established	Получение OCRQ, OCRP, OCCN	Послать CDN Clean up	idle
wait-reply, wait-connect, established	Локальный запрос закрытия	Послать CDN Clean up	idle
wait-tunnel	Локальный запрос закрытия	Clean up	idle

Состояниями, ассоциированными с LNS, для исходящих вызовов являются:

idle, wait-tunnel

Когда инициирован исходящий вызов, сначала создается туннель. Когда туннель создан, посылается сообщение Outgoing-Call-Request LAC и сессия переходит в состояние wait-reply.

wait-reply

Если получено Call-Disconnect-Notify, произошла ошибка, и сессия переводится в исходное состояние idle. Если получено сообщение Outgoing-Call-Reply, вызов находится в развитии и сессия переходит в состояние wait-connect.

wait-connect

Если получено Call-Disconnect-Notify, вызов не состоялся; сессия возвращается в исходное состояние idle. Если получено Outgoing-Call-Connected, вызов прошел, и сессия может осуществлять обмен данными.

established

Если получено Call-Disconnect-Notify, вызов был аннулирован по причине, указанной в кодах результата и причины; сессия возвращается в состояние idle. Если LNS решает завершить сессию, он посылает LAC сообщение Call-Disconnect-Notify и затем переводит сессию в исходное состояние idle.

7.6. Ликвидация туннеля

Разрыв туннеля происходит в случае посылки партнером сообщения Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать определенное время отклика на это сообщение, прежде чем ликвидировать управляющую информацию, имеющую отношение к туннелю. Получатель этого уведомления должен послать подтверждение получения этого сообщения и затем ликвидировать управляющую информацию.

Конкретная программная реализация может использовать определенный алгоритм принятия решения о разрыве управляющего соединения. Некоторые реализации могут оставить туннель открытым на некоторое время. Другие могут решить закрыть туннель немедленно после разрыва последнего соединения пользователей.

8. Реализация L2TP через специфическую среду

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

8.1. L2TP через UDP/IP

L2TP использует зарегистрированный UDP-порт 1701 [RFC1700].

Весь L2TP-пакет, включая поле данных и L2TP-заголовок, пересылается внутри UDP-дейтограммы. Создатель L2TP-туннеля выбирает доступный UDP-порт ( который может быть или не быть 1701), и посылает пакет по нужному адресу места назначения с номером порта 1701. Получатель выбирает свободный номер порта в своей системе (который может быть или не быть 1701), и посылает отклик инициатору по его номеру порта и адресу. Раз номера портов отправителя и получателя определены, они должны оставаться неизменными в течение всей жизни туннеля.

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

По умолчанию для любых реализаций L2TP должно быть активизировано контрольное суммирование UDP как для управляющих, так и информационных сообщений. Реализация L2TP может предоставить опцию, способную блокировать контрольное суммирование UDP-дейтограмм для информационных сообщений. Рекомендуется, чтобы контрольные суммы UDP были всегда активированы для управляющих сообщений.

Порт 1701 используется как пакетами L2F [RFC2341], так и L2TP. Поле версия в каждом из заголовков может использоваться, чтобы отличить пакеты этих двух типов (L2F использует значение 1, а версия L2TP, описанная в этом документе, использует 2). Реализация L2TP, работающая в системе, которая не поддерживает L2F, должна отбрасывать все L2F-пакеты.

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

Молчаливое отбрасывание пакетов может оказаться проблематичным для некоторых протоколов.

Если в PPP разрешена надежная доставка [RFC1663], никакой выше расположенный протокол не может столкнуться с потерей пакетов. Если в L2TP разрешена нумерация пакетов, L2TP может контролировать потерю пакетов. В случае LNS, PPP и L2TP стеки присутствуют в LNS, и потеря пакета может регистрироваться, как если бы пакет получен с неверной CRC. Когда клиенты LAC и PPP физически различны, возможна аналоговая сигнализация, реализуемая путем посылки PPP-клиенту пакета с неверной контрольной суммой. Заметим, что это сильно усложнит отладку канальных программ клиента, так как статистика клиента не сможет отличить истинные ошибки транспортной среды от ошибок, инициированных LAC. Эта техника нереализуема на аппаратном уровне.

Если используется VJ-сжатие, и не разрешена ни надежная доставка в PPP, ни нумерация пакетов, каждый потерянный пакет будет приводить к вероятности 2-16 того, что сегмент TCP будет переадресован с неверным содержимым [RFC1144]. Там где вероятность потери велика, не следует использовать сжатие заголовков TCP-сегментов.

8.2. IP

При работе в IP-среде протокол L2TP должен обеспечить UDP-инкапсуляцию, описанную в 8.1. Другие конфигурации (возможно соответствующие формату со сжатием заголовков) могут быть определены и доступны в качестве конфигурируемой опции.

9. Соображения безопасности

Протокол L2TP сталкивается при своей работе с несколькими проблемами безопасности. Ниже рассмотрены некоторые подходы для решения этих проблем.

9.1. Безопасность на конце туннеля

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

Для реализации аутентификации LAC и LNS должны использовать общий секретный ключ.

Каждая из сторон использует один и тот же ключ, когда выполняет роль аутентификатора и аутентифицируемого. Так как используется только один ключ, AVP аутентификации туннеля несут в себе разные значения полей в CHAP ID для вычисления дайджеста каждого сообщения, чтобы противостоять атакам воспроизведения.

Assigned Tunnel ID и Assigned Session ID (смотри раздел 4.4.3) должны быть выбраны непредсказуемым образом. Такая методика препятствует деятельности хакеров, которые не имеют доступа к пакетам, которыми обмениваются LAC и LNS.

9.2. Безопасность пакетного уровня

Обеспечение безопасности L2TP требует, чтобы транспортная среда могла обеспечить шифрование передаваемых данных, целостность сообщений и аутентификацию услуг для всего L2TP-трафика. Этот безопасный транспорт работает с пакетом L2TP в целом и функционально независим от PPP и протокола, вложенного в PPP. Как таковой, L2TP ответственен за конфиденциальность, целостность и аутентифицированность L2TP-пакетов внутри туннеля (LAC и LNS).

9.3. Безопасность от начала до конца

Защищая поток L2TP-пакетов, так как это делает безопасный транспорт, мы защищаем данные, передаваемые по PPP-туннелю от LAC к LNS. Такая защита не должна рассматриваться как замена для безопасности точка-точка при передаче данных между ЭВМ или приложениями.

9.4. L2TP и IPsec

При работе поверх IP, IPsec (безопасный IP) предоставляет безопасность на пакетном уровне за счет ESP и/или AH. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы Ipsec, как обычные информационные UDP/IP-пакеты.

Помимо транспортной безопасности IP, IPsec определяет режим работы, который позволяет туннелировать IP-пакеты. Шифрование и аутентификация на пакетном уровне, выполняемые режимом туннеля IPsec и средства L2TP, поддержанные IPsec предоставляют эквивалентные уровни безопасности.

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

В модели L2TP-туннеля, аналогичная фильтрация выполняется на PPP- уровне или сетевом уровне поверх L2TP. Эти средства управления доступом на сетевом уровне могут быть реализованы в LNS за счет механизма авторизации, специфицированного производителем, или на сетевом уровне, используя транспортный режим IPsec точка-точка между взаимодействующими ЭВМ.

9.5. Аутентификация прокси PPP

L2TP определяет AVP, которые могут пересылаться в процессе установления сессии с целью передачи PPP аутентификационной информации, полученной в LAC, для перепроверки в LNS (смотри раздел 4.4.5). Это предполагает полное доверие между LAC и LNS. Если LNS решит использовать прокси аутентификацию, она должна быть конфигурируема, требуя нового цикла PPP-аутентификации по инициативе LNS (который может включать или нет новый раунд согласования параметров с LCP).

10. Соображения IANA

Этот документ определяет ряд "магических" числе, которые определяются IANA. Эта секция объясняет критерии, которые должна использовать IANA при присвоении дополнительных чисел в каждый из этих списков. Следующие субсекции описывают политику присвоения для пространства имен, определенных в данном документе.

10.1. Атрибуты AVP

Как это определено в разделе 4.1, AVP содержат поля ID производителя, атрибута и значения. Для ID производителя значение 0 IANA поддерживает регистр присвоенных атрибутов, а в некоторых случаях и значений. Атрибуты 0-39 присвоены согласно тому, как это описано в разделе 4.4. Остальные значения доступны для присвоения при согласовании с IETF [RFC 2434].

10.2. Значения типа сообщения AVP

Как определено в разделе 4.4.1, AVP типа сообщения (тип атрибута 0) имеет значение поддерживаемое IANA. Значения 0-16 определены в разделе 3.2, остальные - могут присваиваться по согласованию с IETF [RFC 2434]

10.3. Значения результирующих кодов AVP

Как это определено в разделе 4.4.2, результирующий код AVP (тип атрибута 1) содержит три поля. Два из них (поля кодов результата и ошибки) имеют значения, обслуживаемые IANA.

10.3.1. Значения поля кода результата

AVP кода результата может быть включено в сообщения CDN и StopCCN. Допустимые значения поля кода результата AVP зависят от значения типа сообщения AVP. Для сообщения StopCCN, значения 0-7 определены в разделе 4.4.2; для сообщения StopCCN, значения 0-11 определены в том же разделе. Оставшиеся значения поля кода результата для обоих сообщений доступны для присвоения через согласование с IETF [RFC 2434].

10.3.2. Значения поля кода ошибки

Значения 0-7 определены в разделе 4.4.2. Значения 8-32767 доступны для присвоения через согласование с IETF [RFC 2434]. Оставшиеся значения поля кода ошибки доступны для присвоения в соответствии с алгоритмом “первый пришел – первым обслужен” [RFC 2434].

10.4. Framing Capabilities & Bearer Capabilities

AVP Framing Capabilities и Bearer Capabilities (определенные в разделе 4.4.3) содержат 32-битовые маски. Дополнительные биты могут быть определены через стандартную процедуру [RFC 2434].

10.5. Значения типов прокси аутентификации AVP

AVP типа прокси Authen (тип атрибута 29) имеет ассоциированное значение, поддерживаемое IANA. Значения 0-5 определены в разделе 4.4.5, оставшиеся значения доступны для присвоения по схеме “первым пришел – первым обслужен” [RFC 2434].

10.6. Биты заголовка AVP

Имеется 4 резервных бита в заголовке AVP. Дополнительные биты должны присваиваться через стандартную процедуру [RFC 2434].

B: Примеры управляющих сообщений

Приложение B: Примеры управляющих сообщений

B.1: Установление туннеля Lock-step

В этом примере, LAC формирует туннель, при этом реализуется обмен сообщениями в обоих направлениях. В этом примере показано, что окончательное подтверждение посылается в сообщении ZLB ACK. Альтернативой может быть подтверждение, пришедшее в сообщении, посланном в ответ на ICRQ или OCRQ, которые направляются стороной, инициировавшей формирование туннеля.

LAC или LNSLNS или LAC

SCCRQ ->

Nr: 0, Ns: 0

Nr: 1, Ns: 0

SCCCN ->

Nr: 1, Ns: 1

Nr: 2, Ns: 1

B.2: Потеря пакета и повторная передача

Существующий туннель имеет новую сессию, запрошенную LAC. Пакет ICRP потерян и должен быть послан LNS повторно. Заметим, что потеря ICRP несет в себе две проблемы: это не только блокирует машину состояний высокого уровня, но и лишает LAC своевременного прихода подтверждения его ICRQ на нижнем уровне.

LAC LNS

ICRQ ->

Nr: 1, Ns: 2

(пакет потерян)

Nr: 3, Ns: 1

(пауза; таймер LAC запускается первым, поэтому первым и срабатывает)

ICRQ ->

Nr: 1, Ns: 2

(Понимая, что он уже видел этот пакет, LNS отбрасывает его и посылает ZLB)

Nr: 3, Ns: 2

(срабатывает таймер повторной передачи LNS)

Nr: 3, Ns: 1

ICCN ->

Nr: 2, Ns: 3

Nr: 4, Ns: 2

Протокол межсетевой передачи больших пакетов (LIP)

4.2.1.4 Протокол межсетевой передачи больших пакетов (LIP)

Новый протокол LIP (Large Internet Packet Protocol, 1992 год) разработан Novell для того, чтобы максимально эффективно реализовать возможности, предоставляемые внешними каналами связи. Для повышения производительности операций чтения и записи разработан также протокол пакетного режима (Burst Mode Protocol). Этот протокол позволяет рабочим станциям передавать один запрос на чтение или запись и получать в ответ до 64 Кбайт данных, не посылая дополнительных запросов (используется технология BNETX и VLM). Длина пакета является результатом соглашения между отправителем и получателем, которое достигается в результате диалога. При этом прикладные программы не должны поддерживать пакетный режим (он реализован в оболочке системы). При использовании протокола пакетного режима BNETX клиент и сервер должны быть соответственно подготовлены. На сервере загружается модуль NLM (PBURST.NLM). Согласование размера пакета реализуется путем посылки оболочкой пакетного режима специального запроса на установление соединения с сервером. Это в свою очередь накладывает ограничение на минимальный размер каждого из используемых буферов. Если совершается попытка клиента установить связь в пакетном режиме с сервером, который этот режим не поддерживает, то будет послано сообщение “NO Such Property”, а обмен будет производиться в обычном режиме (NCP-запрос-отклик). Отличие пакетных режимов в BNETX и VLM заключается в управлении скользящим окном. VLM (VLM.EXE), в отличии от BNETX, не устанавливает верхнего предела размера окна. По умолчанию размер окна (число посланных пакетов без подтверждения получения) при чтении равно 16, а при записи - 10. Формат кадров протокола пакетного режима предполагает наличие IPX-заголовка, за которым следует NCP-заголовок пакетного режима. Далее следуют данные. Формат кадра пакетного режима показан на Рисунок 4.2.1.10. Поле тип запроса NCP-запроса или отклика содержит код 0x7777. Возможные значения флагов перечислены ниже (таблица 4.2.1.6).

Протокол туннелей на сетевом уровне L(LP)

4.4.1.3 Протокол туннелей на сетевом уровне L2 (L2TP)

(W. Townsley, A. Valencia, A., Rubens, G. Pall, G. Zorn, B. Palter, Layer Two Tunneling Protocol "L2TP". RFC-2661, August 1999. Перевод Семенова Ю.А.)

Субформат скрытого AVP

Рис 5. Субформат скрытого AVP

Исходная длина значения атрибута. Это длина кода исходного значения атрибута, которое следует закрыть, в октетах. Необходимо определить исходную длину значения атрибута, так как ее значение теряется при добавлении заполнителя.

Исходное значение атрибута. Значение атрибута, которое должно быть скрыто.

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

Чтобы замаскировать размер скрытого поля данных, используемый субформат может быть дополнен некоторым количеством произвольных октетов. Заполнитель не меняет значения поля, но изменяет величину поля длина AVP, которое было сформировано. Например, если значение атрибута, которое необходимо скрыть, занимает 4 октета, исходная длина AVP будет равна 10 октетам (6 + длина поля значения атрибута). После операции сокрытия, длина AVP станет равной 6 + длина атрибута + размер поля длины исходного значения атрибута + длина заполнителя. Таким образом, если заполнитель имеет 12 октетов, длина AVP будет равна 6 + 4 + 2 + 12 = 24 октетам. Далее, производится хэширование (MD5) для полученного объединения:

+ 2 октета номера атрибута AVP

+ общий секретный ключ

+ случайный вектор произвольной длины

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

Значение хэша MD5 затем объединяется с помощью операции XOR с первыми 16 октетами сегмента субформата скрытого AVP и помещается в поле значения атрибута скрытого AVP. Если субформат скрытого AVP имеет менее 16 октетов, субформат преобразуется так, как если бы поле значения атрибута было дополнено до 16 октетов перед операцией XOR, но модифицируются только действительные октеты, присутствующие в субформате, а длина AVP не изменяется.

Если субформат длиннее 16 октетов, вычисляется второй хэш MD5 для потока октетов, состоящего из общего секретного ключа, за которым следует результат первой операции XOR. Этот хэш объединяется с помощью операции XOR со вторым 16 октетным (или менее) сегментом субформата, а результат помещается в соответствующие октеты поля значения скрытого AVP.

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

Метод сокрытия был адаптирован из RFC 2138 [RFC2138], который был взят из секции "Mixing in the Plaintext" книги "Network Security" Кауфмана, Пелмана и Спенсера [KPS]. Ниже дается детальное пояснение метода:

Берется общий секретный ключ S, случайный вектор RV и значение атрибута AV. Поле значение делится на секции по 16 октетов p1, p2 и т.д.. Последняя секция дополняется до границы в 16 октетов специальным заполнителем. Вычисляются блоки шифротекста c(1), c(2), и т.д.. Мы также определяем промежуточные значения b1, b2, и т.д.

b1 = MD5(AV + S + RV)	c(1) = p1 xor b1
b2 = MD5(S + c(1))	c(2) = p2 xor b2
.	.
.	.
.	.
bi = MD5(S + c(i-1))	c(i) = pi xor bi

строка будет содержать c(1)+c(2)+...+c(i) где + означает объединение.

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

4.4. Обзор AVP

Имя AVP является списком, указывающим типы сообщений, которые использует каждая AVP. После каждого названия AVP следует короткое описание назначения AVP, подробности формата значения атрибута, и любая дополнительная информация, необходимая для правильного использования AVP.

4.4.1. AVP, применимые для всех управляющих сообщений

Тип сообщения (все сообщения)

Тип сообщения AVP, тип атрибута 0, идентифицируют управляющее сообщение и определяет контекст, в котором будет определено точное значение последующих AVP.Поле значения атрибута для этой AVP имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Тип сообщения

6 бит представляют собой

Рисунок 4.

Первые 6 бит представляют собой битовую маску, характеризующую атрибуты AVP.
Два бита определены в этом документе, остальные - зарезервированы на будущее. Зарезервированные биты должны равняться нулю. AVP, полученная с зарезервированным набором бит равным 1, должна рассматриваться как не узнанная AVP.

Обязательный бит M (Mandatory) контролирует реакцию системы на получение нераспознанной AVP. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном с определенной сессией, эта сессия должна быть немедленно завершена. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном со всем туннелем, этот туннель (и все его сессии) должен быть ликвидирован. Если бит M =0, нераспознанную AVP следует игнорировать. Управляющие сообщения должны обрабатываться при этом так, как если бы AVP не было.

Бит сокрытия (H). Идентифицирует скрываемые данные в поле значения атрибута AVP. Эта возможность может использоваться, чтобы исключить передачу важных данных, например пароля пользователя, в незашифрованном тексте AVP. В разделе 4.3 описана процедура выполнения сокрытия AVP.

Длина. Число октетов (включая поля полной длины и маски) в AVP. Длина может быть вычислена как 6 + длина поля значения атрибута в октетах. Поле имеет 10 бит, позволяя закодировать до 1023 октетов в одной AVP. Минимальный код длины AVP равен 6. Если длина равна 6, поле значения атрибута отсутствует.

ID производителя (Vendor ID). IANA определила значения кодов производителей (SMI Network Management Private Enterprise Codes) [RFC1700]. Значение 0, соответствующее атрибутам, адаптированным для IETF, используется для всех AVP, определенных в данном документе. Любой производитель, желающий реализовать свое собственное расширение L2TP, может использовать свой код Vendor ID вместе с частными значениями атрибута, гарантирующие отсутствие столкновений с любыми расширениями других производителей, или будущими расширениями IETF. Заметим, что для ID-производителя выделено 16 бит, что ограничивает максимальное число производителей цифрой 65,535.

Серверы подписки (LISTSERV)

4.5.9 Серверы подписки (LISTSERV)

LISTSERV - система обслуживания и управления списками адресов электронной почты. Она работает в рамках SUN/UNIX, LINUX и др., в интернациональной сети NJE (EARN/Bitnet) и Интернет. Она позволяет группам пользователей, объединенных общим интересом общаться между собой, обеспечивая эффективное использование ресурсов сети. Система дает возможность пользователю найти интересующую его группу, присоединиться к ней и активно участвовать в ее функционировании. LISTSERV управляет почтовым трафиком, осуществляет поиск архивов и файлов. Спектр тем ничем не ограничен, число рубрик превышает 3000.

Доступ к LISTSERV может получить всякий пользователь, кто может посылать электронные сообщения по адресам EARN/Bitnet (в соответствии со стандартом RFC-822) и имеет пригодный к использованию адрес. Отличие от обычной электронной почты заключается в том, здесь вы можете обратиться не только к тем партнерам, адреса которых вы знаете, но и к тем о существовании которых и не подозреваете. Однажды по работе мне потребовалась информация по ультрафиолетовой дозиметрии, я послал запрос в один из серверов и в течение суток получил 6 ответов из США, Канады и Новой Зеландии (среди них Stephan Straus stephen@unicaat.yorku.ca, Martin Brown brauwnma@ucs.oust.edu). Неизвестные мне доселе люди снабдили меня необходимыми данными, указали адреса, где можно найти дополнительную информацию, прислали списки библиографии. Обратите внимание, чтобы однозначно определить, кого я имею в виду, достаточно указать электронный адрес.

Для того, чтобы наладить контакт с LISTSERV нужно послать запрос по адресу: LISTSERV@host-id, где host-id NJE-адрес ЭВМ (например, TAUNIVM.BITNET) или имя INTERNET-домена (в этом случае, VM.TAU.AC.IL). Серверу LISTSERV можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Возможно взаимодействие с LISTSERV и в интерактивном режиме.

Для облегчения связи с сервером необходимо определить узловую ЭВМ в сети EARN/Bitnet.
Пользователи вне сети EARN/ Bitnet могут посылать свои запросы по адресу LISTSERV.NET. Заметьте, что если этот узел еще не определен для вашей сети, вы можете попробовать работать на LISTSERV%LISTSERV.BITNET@CUNYVM.CUNY.EDU. Вы можете также использовать специальный LISTSERV-адрес, чтобы послать e-mail в любой LISTSERV-список. Например, если вы хотите послать электронное сообщение в список BITFTP-L для того, чтобы получить копию программы BITFTP, вы можете сделать это, послав сообщение по адресу BITFTP-L@LISTSERV.NET. Ваше сообщение будет автоматически переадресовано по реальному адресу (в данном случае BITFTP-L@EARNCC.BITNET), когда оно попадет в узел LISTSERV. Существует (на конец 1994 года) более 250 узлов в более чем 30 странах мира, где работают серверы LISTSERV. Вот некоторые из них:

Сервер	Место расположения	Страна
BITNIC	Информационный центр сети BITNET	США
DEARN	GMD, Бонн	Германия
EARNCC	Офис EARN, Париж	Франция
HEARN	Католический университет Nijmegen	Нидерланды
PUCC	Принстонский университет, Нью-Джерси	США
SEARN	Kungliga Tekniska Hoegskolan, Стокгольм	Швеция

Ниже описаны наиболее часто используемые команды. Для получения полного списка команд извлеките LISTSERV User Guide из списка DOC FILELIST по адресу LISTSERV@EARNCC.BITNET.

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

PW=пароль - это ключевое слово служит для описания слова-пароля. Если вы завели слово-пароль для данного LISTSERV-сервера, вы должны в дальнейшем записывать в командном тексте строку PW=, чтобы ваши команды были выполнены. Эта функция создана, чтобы блокировать возможность исполнения команд, используя ваш электронный адрес. Если вы зарегистрировали ваш пароль в сервере LISTSERV, вы обязаны включать PW= во все команды, где это требуется по описанию.

F=формат - это ключевое слово управляет форматом файла (или внутренней структурой файла), в котором он будет вам послан. Если вы не являетесь членом EARN/Bitnet, то LISTSERV будет всегда использовать формат MAIL. В противном случае формат файла зависит от информации, которая содержится в BITEARN NODES файле вашей ЭВМ. BITEARN NODES файл - это специальный файл описания сетей, используемый в EARN/Bitnet сетях. Любой пользователь может затребовать формат, отличный от описанного по умолчанию, посредством F=командное_ключевое_слово в командах, где это требуется опционно. Допустимы следующие форматы файлов:

XXE UUe MIME/text MIME/Appl MAIL

Кроме того, пользователи EARN/Bitnet могут задать:

Netdata Card Disk Punch LPunch VMSdump

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

В рамках LISTSERV почтового списка могут использоваться следующие команды, которые служат для поиска нужного списка и адреса соответствующего сервера, для подписки или ее отмены и т.д.

SUBscribe имя_списка <полное_имя>

Эта команда служит для включения подписчика в список для рассылки. Вы можете использовать эту команду для изменения имени (но не электронного адреса), под которым вы уже известны в списке. имя_списка - это наименование списка, на который вы хотите подписаться. Например, EARN User Group список, находящийся в узле IRLEARN, имеет имя EARN-UG. Не следует путать имя списка с адресом сервера (EARN-UG@IRLEARN). Опционный параметр полное_имя позволяет вам выдать имя, под которым вы хотите фигурировать в списке (это может быть псевдоним). При посылке этой команды в LISTSERV по e-mail полное имя будет взято из поля From:. При посылке этой команды в сервер, где вы уже подписаны, это будет воспринято, как требование об изменении полного имени. Запрос о присоединении к подписному листу может быть обработан тремя путями: подписка может быть OPEN, CLOSED или BY-OWNER. Если это OPEN, вы будете автоматически добавлены в список и получите подтверждение этого. Если это CLOSED, вы будете вычеркнуты из списка рассылки. Если вас там не было, вы получите уведомление о том, что запрос не выполнен. Если же это BY-OWNER, ваш запрос будет переадресован собственнику списка, кто и решит добавлять вас к списку или нет. Адрес, куда будет переправлен ваш запрос, вам будет прислан. Для того, чтобы быть исключенным из списка посылайте команду:

UNSubscribe имя_списка | * <(NETWIDE>

Наличие круглой скобки только слева не является опечаткой. Для того, чтобы ликвидировать подписку по всем спискам LISTSERV, можете использовать "*" вместо имени списка. Если вы хотите, чтобы ваш запрос был передан всем серверам сети, используйте команду (NETWIDE. Эта версия команды рекомендуется при смене вашего электронного адреса или при длительном отпуске. Для получения списка имеющихся списков в сервере LISTSERV используйте команду List.

List <option> <F=формат>

Параметр option может принимать следующие значения:

Short

Отображается резюме всех списков, контролируемых LISTSERV, по одной строке на список. Эта версия реализуется по умолчанию;

Long

(детально) пересылает вам файл (называемый node-name LISTS), содержащий исчерпывающие описания всех списков, поддерживаемых сервером.

Global <эталон>

Выдается полный список всех известных почтовых списков LISTSERV на текущий момент. Этот файл имеет имя LISTSERV LISTS и содержит имена, заголовки и e-mail адреса этих списков. Это очень большой файл, поэтому следует проверить, есть ли у вас достаточно места на диске, прежде чем использовать опцию Global. Опционный параметр эталон может использоваться для того, чтобы выбрать имя списка, заголовок или список адресов.

Для получения листинга почтовых списков используется команда REView. Формат команды:

REView имя_списка <(> <option>

Листинг будет вам переслан в виде файла с именем list-name LIST (или list-name node-name). Почтовый список состоит из двух частей: управляющая секция и подписная секция. Управляющая секция содержит параметры списка, которые включают в себя информацию о том, кто решает вопросы включения в список или его пересмотра, а также архивации. Подписная секция содержит e-mail адреса и имена всех членов списка. REView-команда позволяет вам получить листинг любой или обеих этих секций (по умолчанию - обеих) для любого из списков. Следует иметь в виду, что по решению владельца списка командой REView может выдаваться только список членов этого списка. В этом случае вам не будет позволено просматривать список e-mail адресов, если вы не член списка. Члены списка могут ограничить доступ к своему e-mail адресу по команде REView, если они установили опцию CANCEL. имя_списка - имя LISTSERV-списка, который вы хотите просмотреть. К важным опциям команды REView относятся:

Short

Получаемая информация ограничивается управляющей секцией (только параметры списка).

Countries

Выдается перечень членов списка упорядоченный с учетом национальной принадлежности.

LOCal

Если список имеет пару (соединен с другим списком того же имени, обслуживаемым другим сервером), вы получите полный листинг в отклик на команду REView.

Опция LOCal может использоваться для подавления распространения действия команды REView на другие серверы. В этом случае вы получите листинг только от сервера, куда вы послали запрос.

При подключении к какому-либо списку, вам будет поставлен в соответствие перечень параметров по умолчанию. Эти параметры могут быть вами изменены для любого из списков, где вы являетесь подписчиком. Команда Query позволяет просмотреть текущие значения параметров (опций) для любого списка. Формат команды:

Query имя_списка | *

Параметр имя_списка представляет собой наименование списка, на который вы подписались. Если вы используете символ "*" вместо имени списка, вы получите информацию о ваших личных параметрах для всех списков, на которые вы подписаны.

Для изменения параметров вашей подписки используется команда SET. Она имеет формат:

SET имя_списка | * options

После выполнения команды SET сервер пришлет вам подтверждение успешного изменения параметра по электронной почте. Важными опциями команды SET являются:

Mail | DIGests | INDex | NOMail

Эти опции варьируют способ, которым вы получаете сообщения. Mail означает, что вы хотите получать сообщения по электронной почте (значение по умолчанию).

DIGests и INDex доступны только в случае, если они разрешены собственником списка. DIGests сохраняет все сообщения посланные в список в течении определенного времени. Вместо того, чтобы получать сообщения одно за другим вы получите их единым кластером в определенный день недели или месяца. Обратите внимание, DIGests не редактирует почту и вы получите все сообщения. INDex передаст вам только дату, время, предмет, число строк, имя отправителя и адреса всех сообщений, посланных в список. Текст сообщений передан не будет. Вы можете выбрать и извлечь заинтересовавшие вас сообщения. NoMail означает, что вам не будут пересылаться сообщения. Это полезно при длительной командировке или отпуске. Вернувшись, вы можете послать команду SET c опцией Mail и возобновить присылку сообщений. Предусмотрена возможность изменения формата заголовков почтовых сообщений.

SHORThdr | FULLhdr | IETFhdr | DUALhdr

Все почтовые сообщения состоят из секции заголовка и тела сообщения. Заголовок содержит информацию об отправителе, получателе, дате и времени отправки. Перечисленные выше опции команды SET указывают на тип заголовка почтового сообщения, который вы хотите иметь. SHORThdr означает, что заголовок сообщения будет содержать только самую существенную информацию (например, Date:, To:, From:, Subject:, и Replay-to: поля). Этот вариант работает по умолчанию. Вы можете изменить это, используя опцию FULLhdr, которая означает, что все (даже не существенные) поля заголовка будут присутствовать в почтовом сообщении. Опция IETFhdr означает, что LISTSERV не изменит заголовок, за исключением того, что добавит в заголовок Received: (а также Message-id: и Sender:, если их там не было). Эта опция введена для обеспечения совместимости с SMTP. Наконец DUALhdr очень похожа на SHORThdr за исключением того, что LISTSERV введет заголовок в начало тела сообщения. Следовательно, когда сообщение получено и читается получателем с этой опцией, оно начнется с этой информации (например, первые три строки сообщения могут содержать To:. From:, и Subject). Эта опция удобна для таких почтовых пакетов на PC, где эта информация не отображается.

CONCEAL | NOCONCEAL

указывает на то, хотите вы или нет, чтобы ваше имя и почтовый адрес появлялся в ответ на команду REView, выданную одним из подписчиков списка. По умолчанию работает NONCONCEAL. Обратите внимание, что полный список подписчиков доступен владельцу списка и администратору LISTSERV, вне зависимости от установки этой опции.

Для возобновления вашей подписки необходимо выдать команду COMFIRM. Формат команды:

CONFIRM имя_списка

Некоторые подписные листы требуют регулярного подтверждения подписки (обычно раз в год). Система автоматически напоминает пользователям, что они должны подтвердить свою подписку, т.е. они должны послать команду CONFIRM в течение заданного числа дней. В противном случае клиент будет вычеркнут из списка. Эта команда должна быть послана с того же адреса, по которому было послано напоминание. LISTSERV присылает подтверждение получения команды CONFIRM.

LISTSERV может работать также и как файл-сервер. Поэтому сервер может запоминать файлы и обеспечивать к ним доступ по запросам. Эти файлы запоминаются в рамках иерархической системы filelists. Как и предполагает его название filelist представляет собой специальный файл, который содержит список файлов. Каждая запись в filelist описывает файл, который можно затребовать, давая информацию о его имени, размере, а также коде доступа (File Access Code), который описывает, кто имеет доступ к нему. Эти файлы сами могут быть списками файлов. Таким образом, эта файловая система имеет древовидную структуру.

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

LISTSERV может компоновать один или более файлов в пакет и в таком виде рассылать подписчикам. Это могут быть, например, файлы, необходимые для генерации определенной программы. Пакет декларируется в LISTSERV-filelist через файл, который именуется packet-name $PACKEGE. В нем хранятся описания всех файлов, которые представляют собой пакеты. Любой файл, представляющий собой пакет, может быть извлечен из хранилища с помощью запроса: packet-name PACKAGE. Обратите внимание, что в этом случае символ $ в имени опущен. Таким образом, одна команда позволяет извлечь из депозитария сразу несколько файлов, входящих в пакет.

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

Используйте команду INDex для получения списка файлов из определенного filelist. Формат команды:

INDex <список_файлов> <F=формат>

Параметр список_файлов определяет имя списка, который вас интересует. Если не указано ни какого имени, вам будет прислан индекс корневого списка файлов (именуемого LISTSERV FILELIST).

Команда GET используется для извлечения какого-то определенного файла или пакета файлов из списка файлов, если вам разрешено это делать. Формат команды:

GET имя_файла тип_файла <список_файлов> <F=формат>

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

Для подписки на файлы или пакеты из определенного списка следует использовать команду AFD (Automatic File Distribution). Формат команды:

AFD options

Каждый раз, когда данный список или конкретный файл актуализуется (изменяется), вам будет выслана сервером его копия. Число файлов или пакетов, на которые вы подписаны, не лимитировано. Вы можете в любой момент просмотреть перечень подписки и ликвидировать ее частично или полностью. Параметр options команды AFD может принимать одно из следующих значений:

ADD имя_файла тип_файла <список_файлов> <текст>

<F=формат> <PW=password>

Опция ADD позволяет вам подписаться на файл или пакет, имя_файла и тип_файла характеризует при этом имя и тип файла, на который вы подписались. Если вы хотите, чтобы автоматически в начало каждого присылаемого файла или пакета добавлялся некоторый текст, используйте параметр текст. Если вы пропускаете параметр список_файлов, то параметр текст должен быть помещен в кавычки.

DELete filename filetype <filelist> <PW=password>

Эта опция служит для аннулирования подписки, имена могут содержать символы * (wildcard). Опция List показывает файлы или пакеты, на которые вы в данный момент подписаны. Формат опции:

List <(FORMAT>

Если вы включите опцию (FORMAT, то будет отображен и формат, в котором вам будет присылаться файлы или пакеты. Еще одна команда, которая позволяет осуществить подписку на файлы и пакеты, носит название FUI (File Update Information). Ее формат:

FUI options

Эта команда аналогична AFD за исключением того, что вы в данном случае получаете сообщение об изменении файла или пакета, а не его новую копию. Эта команда допускает следующие опции:

ADD имя_файла тип_файла <список_файлов> <PW=пароль>

Аналог ADD для команды AFD за исключением параметров формат и текст. Опция DELete является полным аналогом одноименной опции команды AFD:

Для получения информации об актуализации файлов или пакетов удобна команда Query File. Параметр список_файлов может быть опущен. Формат команды:

Query File имя_файла тип_файла <список_файлов> <(FLags>

Вы можете задать параметр (Flags, который позволит администрации LISTSERV получить дополнительную техническую информацию о файле, полезную при описании проблем, с которыми вы столкнулись.

Команда PW позволяет вам добавить, изменить или ликвидировать ваше персональное слово-пароль. Команда имеет следующий формат:

PW options

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

ADD new-password

Добавляет новое слово-пароль. Если вы зарегистрировали свое слово-пароль, вы обязаны впредь его использовать всюду (вводить командное ключевое слово PW=), где это требуется опционно.

CHange old-password new-password

Изменяет ваше старое слово-пароль на новое.

DELete old-password

Удаляет ваше слово-пароль из сервера, если вы уже имели его. После этого вы уже не обязаны вводить впредь командное ключевое слово PW=.

Функции LISTSERV DATABASE

LISTSERV позволяет пользователям извлекать старые почтовые сообщения, которые рассылались по списку какое-то время назад. Каждый почтовый список имеет ассоциированную базу данных (обычно называемую notebook или база данных list archive), в которую производится запись рассылаемых сообщений. Такая возможность зависит от хозяина списка и присутствует не всегда. Практически каждый сервер имеет базу данных по узловым ЭВМ сети EARN/Bitnet, которая называется BITEARN. Эта база доступна для всех пользователей. Базовые серверы имеют также базы данных по всем узловым ЭВМ LISTSERV (база имеет название PEERS). Для того, чтобы определить, какие базы данных доступны на данном сервере выдайте команду DATABASE LIST. Для выполнения поиска в базе данных вы можете послать e-mail в LISTSERV c соответствующим запросом в базу данных. Кроме того, пользователи EARN/Bitnet на VM или VMS системах имеют интерактивный доступ к базам данных через программу LDBASE. Для получения более детальной информации пошлите команду Info DATABASE на ближайший сервер.

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

Для получения help-файла из LISTSERV можно выдать команду Info, которая имеет формат:

INFO <тема> <F=формат>

Опция тема должна характеризовать тематику файла, который вы получите в ответ. Если вы пошлете запрос в ближайший (или любой) LISTSERV без указания темы, то получите список возможных тем запросов.

Допустим вы хотите подписаться на список EARNEWS, который находится в узле FRMOP11. Ваше полное имя Yuri A. Semenov. Пошлите следующую команду по адресу LISTSERV@FRMOP11.BITNET:

SUBSCRIBE EARNEWS Yuri A. Semenov

Если вы хотите покинуть INFO-MAC список, где вы были подписчиком ранее, в узле CEARN, выдайте команду:

UNSUBSCRIBE INFO-MAC

которая должна быть послана серверу LISTSERV в CEARN, который управляет списком INFO_MAC. Для того чтобы покинуть все списки LISTSERV, пошлите команду в ближайший сервер LISTSERV:

UNSUBSCRIBE * (NETWIDE

Если вы хотите получить полный список всех списков рассылки, которые в своем названии содержат слово Europe. Пошлите следующую команду ближайшему серверу LISTSERV:

LIST GLOBAL EUROPE

Вы хотите прекратить получение сообщений из всех списков SEARN, где вы состоите подписчиком. Пошлите серверу LISTSERV в SEARN команду:

SET * NOMAIL

Предположим, что вы получили сообщение от сервера LISTSERV в IRLEARN с просьбой подтвердить вашу подписку на список EARN-UG и вы согласны это сделать. Пошлите серверу команду:

CONFIRM EARN-UG

Если вы хотите получить листинг файлов в DOC FILELIST, то следует послать команду INDEX DOC в LISTSERV-сервер EARNCC, где расположен этот список. Эта команда эквивалентна команде GET DOC FILELIST.

Допустим, вы хотите получить файл PCPROG ZIP из списка файлов в формате XXE. Пошлите команду серверу, где размещен этот файл:

GET PCPROG ZIP F=XXE

Предположим, что вы хотите извлечь все файлы, которые образуют пакет под названием PROGRAM (как видно из файла с названием PROGRAM $PACKAGE) из списка файлов SAMPLE. Пошлите команду:

GET PROGRAM PACKAGE SAMPLE

Если вы хотите подписаться на файл под названием BUDGET MEMO в списке файлов EXPENSES с помощью AFD, тогда воспользуйтесь командой:

AFD ADD BUDGET MEMO EXPENSES

Чтобы подписаться на файл с названием VM EMAIL в DOC FILELIST с помощью FUI, вам следует послать следующую команду в LISTSERV узла EARNCC:

FUI ADD VM EMAIL DOC

Ниже приведен пример реализации LIST-сервера, который использован для обмена информацией о московском опорном магистрали (LIST-сервер "FBONE-OP").

LIST-сервер "FBONE-OP" - система обслуживания и управления списком адресов электронной почты. Она позволяет группам ученых, пользующихся услугами южной части московской оптоволоконной магистрали, общаться между собой. Доступ к серверу может получить всякий пользователь, который имеет доступ к электронной почте. Система реализована на версии Majordomo. Это разработка Brent Chapman'а, версия 1.93.

В описании, приведенном ниже параметры, которые помещены в ] являются опционными. Если вы задаете эти параметры, не помещайте их в [ ].

Для того, чтобы наладить контакт с сервером нужно послать запрос по адресу: FBONE-OP-REQUEST@ITEP.RU. Серверу можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Ниже описаны наиболее часто используемые команды. Команды имеют следующий формат: прописные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров.

При работе с LIST-сервером помимо уже описанных (subscribe, unsubscribe, get и index) могут использоваться следующие команды:

which [<address>]

Определить, на какой из списков вы подписаны (или адресат <address>).

who [<list>]

Определить список подписчиков <list>.

info [<list>]

Выдать общую вводную информацию для указанного списка <list>.

lists

Отображает список списков, которые обслуживаются Majordomo-сервером.

end

Блокирует дальнейшую обработку команд (полезно, если вы используете "подпись" в вашей почтовой программе).

Команды должны записываться в тело почтового сообщения (а не в поле Subject) FBONE-OP@ITEP.Ru или FBONE-OP-REQUEST@ITEP.Ru.

В ответ на запрос subscribe вы получите отклик вида:

Received: by ns.itep.ru id AA03442 (5.67a8/IDA-1.5 for semenov); Sun, 26 Feb 1995 12:29:44 +0300

Date: Sun, 26 Feb 1995 12:29:44 +0300

To: semenov

From: MailList

Subject: ITEP MailLists Server results

Reply-To: MailList

>>>> subscribe

Succeeded.

Параметр <list> является опционным, если запрос послан по адресу "<list>-request@ITEP.Ru". В ответ на запрос who сервер выдаст:

From maillist Sun Feb 26 15:46:16 1995

Received: by ns.itep.ru id AA07983

Date: Sun, 26 Feb 1995 15:46:15 +0300

To: semenov

From: MailList

Subject: ITEP MailLists Server results

Reply-To: MailList

>>>> who

Members of list 'fbone-op':

bobyshev

BOBYSHEV@vxdesy.desy.de

bobyshev@x4u2.desy.de

kent@top.rector.msu.su

ks@isf.ru

em@free.net

gonchar@ipsun.ras.ru

noc@radio-msu.net

sid@free.net

nelubov@oea.ihep.su

sakr@itp.ac.ru

leonid@egoshin.ihep.su

semenov

При работе c подписными листами следует прежде всего думать о партнерах по списку. Это занятые люди, поэтому для всеобщего внимания следует выносить лаконичные сообщения, представляющие всеобщий интерес. Частные сообщения лучше посылать только тому, или тем, адресатам, которым это важно знать.

Детальная документация по LISTSERV и связанных с ним услуг доступна в DOC FILELIST по адресу LISTSERV@EARNCC.BITNET. Сюда входит LISTSERV User Guide, который доступен в обычном и postscript форматах. Для получения списка доступной документации используйте команду INDex. Существует несколько списков для обсуждения технических вопросов LISTSERV. Они не предназначены для обычных пользователей, но и не закрыты для них. Это:

LSTSRV-L технический форум LISTSERV.

LSTOWN-L форум хозяев списков LISTSERV.

LDBASE-L форум возможностей баз данных в LISTSERV.

Схема работы протокола LP

Рисунок 1. Схема работы протокола L2TP

Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN. LAC затем прокладывает туннель для PPP-соединения через Интернет, Frame Relay или ATM к LNS, посредством чего осуществляется доступ к исходной LAN (Home LAN). Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккоунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS.

LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC. В этом случае, ЭВМ, содержащая программу LAC клиента, уже имеет соединение с Интернет. Затем создается "виртуальное" PPP-соединение и локальная программа L2TP LAC формирует туннель до LNS. Как и в выше описанном случае, адресация, аутентификация, авторизация и аккоунтинг будут обеспечены областью управления исходной LAN.

Ссылки

11. Ссылки

[DSS1]	ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998
[KPS]	Kaufman, C., Perlman, R., и Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1
[RFC791]	Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC1034]	Mockapetris, P., "Domain Names - Concepts и Facilities", STD 13, RFC 1034, November 1987.
[RFC1144]	Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1661]	Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1662]	Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1663]	Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1700]	Reynolds, J. и J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Смотри также: http://www.iana.org/numbers.html
[RFC1990]	Sklower, K., Lloyd, B., McGregor, G., Carr, D. и T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[RFC1994]	Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1918]	Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. и E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2138]	Rigney, C., Rubens, A., Simpson, W. и S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RFC2277]	Alvestrand, H., "IETF Policy on Character Sets и Languages", BCP 18, RFC 2277, January 1998.
[RFC2341]	Valencia, A., Littlewood, M. и T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2401]	Kent, S. и R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2434]	Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2637]	Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. и G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[STEVENS]	Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9

<
/p>

Приложение A:

Медленный старт в управляющем канале и подавление перегрузки

Хотя каждая из сторон указала максимальный размер окна приема, рекомендуется, чтобы при передаче управляющих пакетов использовался медленный старт и метод подавления перегрузки. Методы, описанные здесь, базируются на TCP-алгоритме подавления перегрузки, как это описано в разделе 21.6 книги “TCP/IP Illustrated”, том I, написанной W. Richard Stevens [STEVENS].

Медленный старт и подавление перегрузки используют несколько переменных. Окно перегрузки (CWND) определяет число пакетов, которые отправитель может послать, не дожидаясь подтверждения. Размер CWND расширяется и сокращается так, как это описано ниже. Заметим, однако, что CWND никогда не должно превышать размера окна, полученного из AVP приемного окна (далее предполагается, что любое увеличение ограничивается размером приемного окна). Переменная SSTHRESH определяет, когда отправитель переходит от медленного старта к подавлению перегрузки. Медленный старт используется, когда CWND меньше SSHTRESH.

Отправитель начинает работу с фазы медленного старта. Начальный размер CWND равен одному пакету, а уровень SSHTRESH в начальный момент определяется размером окна (полученным из AVP приемного окна). Отправитель передает один пакет и ждет подтверждения получения. Когда подтверждение получено, окно перегрузки увеличивается на единицу и становится равным двум. Во время медленного старта, размер CWND увеличивается на единицу при получении каждого ACK. Увеличение CWND на 1 при получении ACK приводит к удвоению CWND за время RTT, что эквивалентно экспоненциальному росту. Когда значение CWND достигает SSHTRESH, фаза медленного старта завершается и начинается подавление перегрузки.

При подавлении перегрузки, CWND расширяется более медленно. В частности, оно увеличивается на 1/CWND для каждого полученного подтверждения ACK. Расширение окна на фазе подавления перегрузки является линейным, с увеличением CWND на 1 за время RTT.

Когда происходит перегрузка (индицируемая повторной передачей пакета) половина CWND записывается в SSTHRESH, а CWND делается равным 1.Отправитель после этого возвращается в режим медленного старта.

Структура протокола LP

Рисунок 2.0. Структура протокола L2TP

На Рисунок 2.0 показано взаимоотношение PPP-кадров и управляющих сообщений по управляющему и информационному каналам L2TP. PPP-кадры передаются через ненадежный канал данных, инкапсулированные сначала в L2TP, а затем в транспортные пакеты, такие как UDP, Frame Relay, ATM и т.д.. Управляющие сообщения посылаются через надежный управляющий канал L2TP, который передает пакеты в пределах того же пакетного транспорта.

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

3.1. Формат заголовка L2TP

Пакеты L2TP для контрольного и информационного каналов используют один и тот же формат заголовка. Заметим, что поля длина, Ns и Nr - опционные для информационных пакетов, являются обязательными для всех управляющих сообщений.

Заголовок имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 31

Версия

Длина (опц)

ID туннеля

ID сессии

локальных дескрипторов

Таблица локальных дескрипторов

LEA

Load Effective Address

Эффективный адрес загрузки

LEAF

Law Enforcement Access Field

LEC

LAN Emulation Client

Клиент эмуляции локальной сети

LECS

LAN Emulation Configuration Server

Конфигурирующий сервер эмуляции LAN

LED

Light Emitting Diode

Светоизлучающий диод

LEL

Link, Embed and Launch-to-edit

Связать, загрузить и запустить редактор [Lotus]

LEO

Low Earth Orbit

Низкая спутниковая орбита

LEM

Language Extension Module

Модуль языкового расширения

LEN

Low Entry Networking

LES

LAN Emulation Server

Сервер эмуляции LAN (ATM)

Line Feed

Перевод строки

LFA

Loss of Frame

Потеря кадра

LFI

Last File Indicator

Индикатор последнего файла

LFN

Long, Fat pipe Network (pronounced as "elephant")

Протяженная сеть с высокой пропускной способностью (сеть с большим произведением полосы на RTT)

LFU

Least Frequently Used

Наиболее редко используемый

LGDT

Load Global Descriptor Table

Загрузка таблицы глобальных описателей

LGN

Logical Groupe Node

Узел логической группы

Length Indicator

Индикатор длины

.LIB

Library

Расширение имени библиотечного файла

LICS

Lotus International Character Set

Интернациональный набор символов [LDC]

LIDT

Load Interrupt Descriptor Table

Загрузить таблицу описателей прерываний

LIEP

Large Internet Exchange Packet

Большой пакет обмена для Интернет [Novell]

LIF

Low Insertion Force

Малое усилие вставления

LIFA

Loop Initialization Fabric Assigned

Процедура присвоения адресов при инициализации структуры (Fibre Channel)

LIFO

Last In First OUT

Последний вошедший выходит первым (память)

LIH

Logical Interface Handle

Дескриптор логического интерфейса

LILO

Last In, Last Out

Последний пришедший выходит последним

LIM

Lotus/Intel/Microsoft

LIMA

Lotus/Intel/Microsoft/AST

LIMEMS

Lotus/Intel/Microsoft EMS

LIMS

Library Information Management System

Библиотечная система управления информацией

LION

Local Integrated Optical Network

Локально интегрированная оптическая сеть

LIP

Large Internet Packet Protocol (Novell)

Протокол передачи больших информационных пакетов

Loop Initialization Procedure

Процедура инициализации кольца (Fibre Channel)

LIPS

Logical Inferences Per Second

Число логических операций в секунду

LIS

Logical IP Subnet

Логическая IP-субсеть

LISM

Loop Initialization Select Master

Сигнал выбора сервера инициализации кольца (Fibre Channel)

LISP

List Processing

Язык для работы со списками

LLAP

LocalTalk Link Access Protocol

Протокол доступа к каналу ArcNet для AppleTalk

LLC

Low Layer Compatibility

Совместимость на нижнем уровне (ISDN Setup-параметр)

Logical Link Control

Логическое управление каналом (FDDI; 802.2)

LLDT

Load Local Descriptor Table

Загрузка таблицы локальных дискрипторов

LLF

Low Level Format

Формат низкого уровня

LLNL

Lawrence Livermore National Laboratory

Ливерморская национальная лаборатория имени Лоуренса

LLRC

Length/Longitudinal Redundancy Checkword

Продольная контрольная сумма

LMBCS

Lotus Multibyte Character Set

Мультибайтовый набор символов [Lotus]

LME

Layer Management Entity

Объект уровня управления

LMI

Local Management Interface

Интерфейс локального управления

Layer Management Interface

Интерфейс управления уровнем

LMSW

Load Machine Status Word

Загрузить слово состояния

LM/X

LAN Manager for Unix

Менеджер управления локальной сетью для UNIX

LNC

Local Node Clock

Таймер локального узла

LNDI

Lotus Notes: Document Imaging

Заметки Lotus: отображение документов

LNM

LAN Network Manager

Менеджер локальной сети (IBM)

LNNI

LAN Emulation Network-to-Network Interface

Межсетевой интерфейс эмуляции LAN

LOC

Loop On-Line Control

Контроль в реальном масштабе времени

Line of Communication

Линия связи

LOCIS

Library of Congress Information System

Информационная система библиотеки конгресса

LODSB

Load String Byte

Байт загрузки строки

LOF

Loss of Frame

Потеря кадра

LOI

Lower Order Interface

Интерфейс сборки VC нижнего уровня

LOM

Loss Of Multiframe

Потеря мультифрейма

LOP

Loss Of Pointer

Потеря указателя (в VC SDH)

LORE

Line Oriented Editor

Строчный редактор

LOS

Loss Of Signal

Потеря сигнала

LPA

Lower order Path Adaptation

Адаптация к маршруту VC нижнего уровня

LPC

Local Procedure Call

Локальный вызов процедуры

Lower order Path Connection

Соединение нескольких VC нижнего уровня

LPD

Line Printer Daemon protocol

Протокол демона для принтера (UNIX-TCP/IP; RFC 1179)

LPDA

Line Problem Determination Application

Приложение, выявляющее проблемы на линии

LPF

League for Programming Freedom

Название организации, выступающей против патентов на программное обеспечение

LPI

Lines Per Inch

Линий на дюйм

LPM

Lines Per Minute

Строк в минуту

LPN

Logical Page Number

Логический номер страницы

LPOM

Lower order Path Overhead Monitor

Мониторинг POH VC нижнего уровня

LPP

Lightweight Presentation Protocol

Простой протокол презентаций

LPR

Local Primary Reference

Локальный первичный эталон

LPS

Low-Power Schottky

Шоттки прибор с малым потреблением

LPT

Line Printer

Печатающее устройство

Lower order Path Termination

Начало/конец маршрута VC нижнего уровня

Letter Quality

Полиграфическое качество

LQM

Link Quality Monitoring

Мониторирование качества канала (протокол)

Line Regenerator

Линейный регенератор

LRAAM

Labeling RAAM

LRC

Longitudinal Redundancy Check

Проверка продольной контрольной суммы

Local Register Cache

Регистровый локальный буфер

Local Routing Center

Локальный центр маршрутизации

LRE

Linguistic Research and Engineering

Лингвистические исследования и инженерия

LRL

Least Recently Loaded

Загруженный последним

LRM

Language Reference Manual

Руководство для словаря

LRU

Least Recently Used (memory)

Использовался последним (блок памяти)

Least Significant

Самый младший

LSA

Line Sharing Adapter

Адаптер для совместного использования линии

Link State Adverticement

Оповещение о состоянии канала

Link Subnetwork Access

Доступ к каналу субсети

LSAP

Link Service Access Point

Точка доступа к каналу (IEEE 802)

LSAPI

License Services Application Program Interface

Программный интерфейс для лицензионных приложений

LSB

Least Significant Bit (Byte)

Младший бит (байт)

LSC

Least Significant Character

Младший символ

LSL

Link Support Layer

Уровень поддержки канала

Link Service Layer

Уровень обслуживания канала

Load Segment Limit

Граница загрузки сегмента

LSP

Link State Packet

Пакет состояния канала

Label Switching Pass

Путь при коммутации по метке (VPN)

LSRR

Loose Source and Record Route

LTE

Line Terminal Equipment

Линейное терминальное оборудование

LTI

Loss of Timing Inputs

Потеря синхронизации на входе

LTR

Left-To-Right

Слева направо

Letter

Буква

Load Task Register

Регистр загрузки задания

Logical Unit

Логический блок

LUA

Logical Unit Application (interface)

Применение логического блока

LUB

Least Upper Bound

Наименьший верхний предел (RSVP)

LUG

Lower order Unequipped Generator

Формирование незагруженного VC нижнего уровня (SDH)

LUI

Local User Input

Локальный пользовательский ввод

LUN

Logical Unit

Логический блок

LUNI

LAN-User Network Interface

Интерфейс “Пользователь-локальная сеть”

LUT

Lookup Table

Таблица просмотра

LVQ

Learning Vector Quantization

Дискретизация вектора обучения (нейронные сети)

LVQTC

Learning Vector Quantization with Training Count

Дискретизация вектора обучения со счетом предъявляемых объектов (нейронные сети)

LWC

Leave Word Calling

LWS

Lint White Space

Строчный пробел (SP, TAB, CR)

LXC

Local Cross-Connect

Локальный кросс-коммутатор

LZW

Lempel-Ziv-Walsh

Название алгоритма сжатия информации

Значения поля флаги

Таблица 4.2.1.4.1 Значения поля флаги

Флаг

Описание

sys

При равенстве 1 указывает на то, что это системный пакет и не несет в себе данных

sak

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

eob

Равенство 1 показывает, что пакет содержит последнюю порцию данных, присланных отправителем.

bsy

Пока не используется, зарезервирован для индикации занятости сервера.

abt

Равенство 1 сообщает клиенту о том, что сессия прервана.

Топология

2. Топология

На диаграмме (Рисунок 1.) показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенной в LAN.

определяет механизм инкапсуляции для транспортировки

1.0. Введение

Протокол PPP [RFC1661] определяет механизм инкапсуляции для транспортировки мультипротокольных пакетов для соединений точка-точка сетевого уровня L2. Обычно, пользователь получает соединение L2 с сервером доступа NAS (Network Access Server) посредством одной из следующих технологий: посредством модема через коммутируемую телефонную сеть, ISDN, ADSL, и т.д. Далее через это соединение реализуется протокол PPP. В такой конфигурации терминальная точка L2 и сессии PPP находится в одном и том же физическом устройстве (NAS). Разрабатывается версия протокола для безопасного удаленногго доступа через L2TP (RFC-2888).
Протокол L2TP расширяет модель PPP, позволяя размещение терминальных точек L2 и PPP в различных физических устройствах, подключенных к сети с коммутацией пакетов. В L2TP, пользователь имеет соединение L2 с концентратором доступа (например, модемным пулом, ADSL DSLAM, и т.д.), а концентратор в свою очередь туннелирует индивидуальные PPP-кадры в NAS. Это позволяет разделить обработку PPP-пакетов и реализацию шлюза L2.
Очевидным преимуществом такого разделения является то, что вместо требования завершения соединения L2 в NAS, соединение может завершаться в локальном концентраторе, который затем продлевает логический канал PPP через общую инфраструктуру, такую как, например, Интернет. C точки зрения пользователя нет никакой разницы между завершением туннеля на уровне L2 в NAS или через L2TP.
Многоканальный PPP [RFC1990] требует, чтобы все каналы, образующие многоканальную связь, были объединены в группу с помощью одного NAS. Благодаря возможности формирования сессий PPP с оконечными адресами, отличными от точки присоединения, L2TP может использоваться для схем, когда все каналы приходят на вход одного NAS.

1.1. Терминология

Аналоговый канал	Коммуникационный канал, который обычно обеспечивает при передаче голоса полосу 3.1 кГц в обоих направлениях.
Пары атрибут	значение AVP (Attribute Value Pair)Объединение уникального атрибута (представляемого в виде целого числа) и действительного значения этого атрибута. Пара AVP имеет переменную длину. Несколько AVP образуют управляющие сообщения, которые используются при установлении, поддержке и ликвидации туннеля.
Вызов	Соединение (или попытка соединения) между удаленной системой и LAC (L2TP Access Concentrator). Например, телефонный вызов через обычную коммутируемую телефонную сеть PSTN. Вызов (входящий или исходящий), который успешно осуществил связь между удаленной системой и LAC, реализуется в ходе L2TP-сессии при условии, что туннель между LAC и LNS (L2TP Network Server) уже создан. (Смотри также: сессия, входящий вызов, исходящий вызов).
Вызванный номер	Телефонный номер, использованный для связи с получателем вызова.
Вызывающий номер	Телефонный номер, откуда пришел вызов.
CHAP	Challenge Handshake Authentication Protocol [RFC1994], криптографический PPP-протокол для аутентификации вызова/отклика, в котором пароль не передается открытым текстом.
Управляющее соединение	Управляющее соединение работает в пределах имеющейся полосы туннеля и служит для установления, аннулирования и поддержания сессий и самого туннеля.
Управляющие сообщения	Управляющими сообщениями обмениваются LAC и LNS, работающие в пределах имеющейся полосы туннеля. Управляющие сообщения контролируют сам туннель и реализуемые через него сессии.
Цифровой канал	Коммутируемый канал, по которому передаются цифровые данные в обоих направлениях.
DSLAM	Digital Subscriber Line (DSL) Access Module (модуль доступа клиентов к цифровым линиям). Сетевой прибор, используемый для реализации DSL-сервиса. Это обычно концентратор индивидуальных DSL-линий, размещенный в центральном офисе (CO), или местный коммутатор.
Входящий вызов	Вызов, полученный LAC для туннелирования в LNS (смотри Вызов, Исходящий вызов).
Концентратор доступа L2TP (LAC)	Узел, который действует в качестве одной из сторон L2TP-туннеля и является партнером для LNS (L2TP Network Server). LAC размещается между LNS и удаленной системой, переадресуя им пакеты. Пакеты, посланные от LAC к LNS, требуют туннелирования с помощью протокола L2TP, как это определено в данном документе. Соединение между LAC и удаленной системой является локальным (смотри: клиент LAC) или осуществляется через канал PPP.
Сетевой сервер L2TP (LNS)	Узел, который работает в качестве одного из концов L2TP туннеля, и является партнером для LAC (L2TP Access Concentrator). LNS является логической терминальной точкой PPP-сессии, которая организует туннель между удаленной системой и LAC.
Домен управления (MD)	Сеть или сети, управляемые общей администрацией administration, политикой или системой. Например, доменом управления LNS может быть корпоративная сеть, которую он обслуживает. Доменом управления LAC может быть сервис-провайдер Интернет, которым он управляет.
Сервер доступа к сети (NAS)	Прибор, предоставляющий доступ к локальной сети для пользователей удаленной сети, такой как общедоступная коммутируемая телефонная сеть (PSTN). NAS может выполнять функцию LAC, LNS или и того и другого.
Исходящий вызов	Вызов, сделанный LAC, для туннелирования в LNS (смотри вызов, входящий вызов).
Партнер	При использовании в контексте L2TP, партнер относится к LAC или LNS. Партнером LAC является LNS и наоборот. При использовании в контексте PPP, партнером является любая из сторон PPPсоединения.
POTS	Plain Old Telephone Service (обычная телефонная служба).
Удаленная система	Оконечная система или маршрутизатор, соединенный с удаленной сетью (т.e. PSTN), которая является инициатором или получателем вызова. Относится также к клиенту, подключающемуся через коммутируемую телефонную сеть (dial-up).
Сессия	Протокол L2TP ориентирован на соединение. LNS и LAC поддерживают состояния для каждого вызова, который инициирован или воспринят LAC. Сессия L2TP формируется между LAC и LNS, когда создано соединение точка-точка PPP между удаленной системой и LNS. Дейтограммы, относящиеся к соединению PPP, пересылаются по туннелю, организованному между LAC и LNS. Существует полное соответствие между сессиями L2TP и сопряженными с ними вызовами. (Смотри также: вызов).
Туннель	Туннель между LAC и LNS. Туннель состоит из управляющего соединения и нуля или более сессий L2TP. Туннель передает инкапсулированные дейтограммы PPP и управляющие сообщения между LAC и LNS.
Сообщение с нулевой длиной тела (ZLB)	Управляющий пакет, имеющий только заголовок L2TP. ZLB-сообщения используются в качестве откликов в управляющем канале.