Формат кадра пакетного режима
Рисунок 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 |
Сообщения об ошибках
15 |
(WEN) |
WAN-Error-Notify |
Управление сессией PPP
Литература
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 |
M |
H |
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.
Эта AVP может быть скрытой (бит H может быть 0 или 1). M-бит для этой AVP должен быть равен 1. Длина (до сокрытия) этой AVP равна 6 плюс длина телефонного номера.
Субадрес (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 |
Зарезервировано для будущих определений типа кадрового обмена |
A |
S |
Поле значения атрибута для 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)
5.7. Разрыв контрольного соединения
Разрыв контрольного соединения может быть инициирован LAC или LNS и выполняется путем посылки одного управляющего сообщения StopCCN. Получатель StopCCN должен послать ZLB ACK, чтобы подтвердить получение сообщения, и поддерживает состояние управляющего соединения на уровне достаточном для корректного приема StopCCN, а также повторения цикла, если ZLB ACK потеряно. Рекомендуемое время повторения цикла равно 31 секунде (смотри раздел 5.8). Ниже приводится типовой обмен управляющими сообщениями:
LAC или LNS LAC или LNS
StopCCN ->
(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
SCCCN ->
Nr: 1, 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)
(срабатывает таймер повторной передачи LNS)
ICCN ->
Nr: 2, Ns: 3
Протокол межсетевой передачи больших пакетов (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 |
T |
L |
x |
x |
S |
x |
O |
P |
x |
x |
x |
x |
Версия |
Длина (опц) |
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) |
LF |
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 |
Узел логической группы |
LI |
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 нижнего уровня |
LQ |
Letter Quality |
Полиграфическое качество |
LQM |
Link Quality Monitoring |
Мониторирование качества канала (протокол) |
LR |
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) |
Использовался последним (блок памяти) |
LS |
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 |
Регистр загрузки задания |
LU |
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-сообщения используются в качестве откликов в управляющем канале. |