новости
статьи
.технологии

Протоколы защищенных каналов. часть 2. L2TP

введение

Протокол PPP определяет механизм инкапсуляции для транспортировки мультипротокольных пакетов для соединений точка-точка сетевого уровня L2. Обычно, пользователь получает соединение L2 с сервером доступа NAS (Network Access Server) посредством одной из следующих технологий: посредством модема через коммутируемую телефонную сеть, ISDN, ADSL, и т.д. Далее через это соединение реализуется протокол PPP. В такой конфигурации терминальная точка L2 и сессии PPP находится в одном и том же физическом устройстве (NAS).
Протокол L2TP расширяет модель PPP, позволяя размещение терминальных точек L2 и PPP в различных физических устройствах, подключенных к сети с коммутацией пакетов. В L2TP, пользователь имеет соединение L2 с концентратором доступа (например, модемным пулом, ADSL DSLAM, и т.д.), а концентратор в свою очередь туннелирует индивидуальные PPP-кадры в NAS. Это позволяет разделить обработку PPP-пакетов и реализацию шлюза L2.
Очевидным преимуществом такого разделения является то, что вместо требования завершения соединения L2 в NAS, соединение может завершаться в локальном концентраторе, который затем продлевает логический канал PPP через общую инфраструктуру, такую как, например, Интернет. C точки зрения пользователя нет никакой разницы между завершением туннеля на уровне L2 в NAS или через L2TP.
Многоканальный PPP требует, чтобы все каналы, образующие многоканальную связь, были объединены в группу с помощью одного NAS. Благодаря возможности формирования сессий PPP с оконечными адресами, отличными от точки присоединения, L2TP может использоваться для схем, когда все каналы приходят на вход одного NAS.

топология

На рисунке 1 показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенной в LAN.



Рис. 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.

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

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

PPP кадры

L2TP Информационные сообщения L2TP Управляющие сообщения
L2TP Информационный канал (ненадежный) L2TP Канал управления (надежный)

Транспортировка пакетов (UDP, FR, ATM, etc.)

Рис. 2.

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

формат заголовка L2TP

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

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

 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Версия| Длина (опц) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID туннеля | ID сессии |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (опц) | Nr (опц) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Величина смещения (опц) | Заполнитель (опц) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис. 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, в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля Ver должны отбрасываться. Поле длина указывает общую длину сообщения в октетах.
ID-туннеля содержит идентификатор управляющего соединения. Идентификаторы туннеля L2TP имеют только локальное значение. То есть, разные концы одного туннеля должны иметь разные ID. ID туннеля в каждом сообщении должно быть тем, которое ожидает получатель. ID туннеля выбираются при формировании туннеля.
ID-сессии определяет идентификатор для сессии данного туннеля. Сессии L2TP именуются с помощью идентификаторов, которые имеют только локальное значение. ID-сессии в каждом сообщении должно быть тем, которое ожидает получатель. ID-сессии выбираются при формировании сессии.
Ns определяет порядковый номер информационного или управляющего сообщения, начиная с нуля и увеличиваясь на 1 (по модулю 216) для каждого посланного сообщения.
Nr содержит порядковый номер, который ожидается для следующего сообщения. Таким образом, Nr делается равным Ns последнего по порядку полученного сообщения плюс один (по модулю 216). В информационных сообщениях, Nr зарезервировано и, если присутствует (как это определяется S- битом), должно игнорироваться при получении.
Поле величина смещения (Offset Size), если имеется, специфицирует число октетов после заголовка L2TP, где должно начинаться поле данных. Содержимое заполнителя смещения не определено. Если поле смещения присутствует, заголовок L2TP завершается после завершающего октета заполнителя смещения.

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

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

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

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

16 (SLI) Set-Link-Info

формат AVP

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

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Длина | ID производителя |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Тип атрибута | Значение атрибута...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Продолжение поля значение атрибута до границы, заданной полем длина..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рис. 4.

Первые 6 бит представляют собой битовую маску, характеризующую атрибуты AVP.

Два бита определены в этом документе, остальные — зарезервированы на будущее. Зарезервированные биты должны равняться нулю. AVP, полученная с зарезервированным набором бит равным 1, должна рассматриваться как не узнанная AVP.
Обязательный бит M (Mandatory) контролирует реакцию системы на получение нераспознанной AVP. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном с определенной сессией, эта сессия должна быть немедленно завершена. Если бит M =1 для нераспознанной AVP в сообщении, ассоциированном со всем туннелем, этот туннель (и все его сессии) должен быть ликвидирован. Если бит M =0, нераспознанную AVP следует игнорировать. Управляющие сообщения должны обрабатываться при этом так, как если бы AVP не было.
Бит сокрытия (H). Идентифицирует скрываемые данные в поле значения атрибута AVP. Эта возможность может использоваться, чтобы исключить передачу важных данных, например пароля пользователя, в незашифрованном тексте 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.
Тип атрибута: 2-октетное значение с уникальной интерпретацией для совокупности AVP данного ID-производителя.
Значение атрибута. Действительное значение атрибута для заданного Vendor ID и типа атрибута. Оно следует немедленно после поля типа атрибута, и занимает все пространство октетов, отведенное значением поля длина (т.e., длина минус 6 октетов заголовка). Это поле отсутствует, если длина равна 6.

обзор AVP

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

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

Тип сообщения (все сообщения). Тип сообщения AVP, тип атрибута 0, идентифицируют управляющее сообщение и определяет контекст, в котором будет определено точное значение последующих AVP.
Тип сообщения характеризуется целым 2-октетным числом без знака. Тип сообщения AVP должен быть первым AVP в сообщении, который следует непосредственно сразу за заголовком управляющего cообщения
Случайный вектор (все сообщения). Случайный вектор AVP, тип атрибута 36, используются для разрешения сокрытия значения атрибута AVP.

коды результата и ошибки

Результирующий код (CDN, StopCCN). Результирующий код AVP, тип атрибута — 1, индицируют причину завершения работы управляющего канала или сессии.

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

Версия протокола (SCCRP, SCCRQ). Версия протокола AVP, тип атрибута — 2, указывает на версию протокола L2TP отправителя.
Возможность работы с кадрами (SCCRP, SCCRQ). Возможность работы с кадрами AVP, тип атрибута — 3, предоставляет партнеру указание на типы кадров, которые будут приняты или запрошены отправителем.
Возможности носителя (SCCRP, SCCRQ). AVP возможностей носителя, тип атрибута — 4, предоставляют партнеру указание на типы носителя, поддерживаемые аппаратным интерфейсом отправителя для исходящих вызовов.
Арбитр конфликта (Tie Breaker (SCCRQ)). AVP арбитра конфликта, тип атрибута — 5, указывает, что отправитель желает иметь один туннель между заданной парой LAC-LNS.
Фирменная версия (Firmware Revision) (SCCRP, SCCRQ). Фирменная версия AVP, тип атрибута 6, указывает на фирменную версию прибора, пославшего сообщение.
Имя ЭВМ (SCCRP, SCCRQ). AVP имени ЭВМ, тип атрибута 7, указывает на имя ЭВМ, реализующей функцию LAC или LNS.
Имя производителя (SCCRP, SCCRQ). AVP имени производителя, тип атрибута 8, содержит специфическую для производителя строку, которая характеризует тип используемого LAC или LNS.
ID, присвоенное туннелю (SCCRP, SCCRQ, StopCCN). AVP ID, присвоенного туннелю, тип атрибута 9, несет в себе ID, присвоенное туннелю отправителем. ID, присвоенное туннелю, содержит в себе 2-октетное целое неравное нулю число без знака.
Размер приемного окна (Receive Window Size (SCCRQ, SCCRP)). Размер приемного окна AVP, тип атрибута 10, специфицирует размер приемного окна, которое предлагает удаленный партнер. Размер окна характеризуется 2-октетным целым числом без знака.
Приглашение (Challenge (SCCRP, SCCRQ)). AVP приглашения, тип атрибута 11, указывает, что отправивший его партнер хочет аутентифицировать концы туннеля, используя CHAP-стиль аутентификационного механизма. Вызов содержит один или более октетов произвольной информации.
Отклик на приглашение (Challenge Response (SCCCN, SCCRP)). AVP отклика, тип атрибута 13, направляет ответ на полученное сообщение. Поле отклик содержит 16 октетов, соответствуя CHAP-стилю отклика на вызов.
Эта AVP должна присутствовать в SCCRP или SCCCN, если приглашение было получено в предыдущем SCCRQ или SCCRP. Для целей вычисления значения ID в CHAP-отклике используется код типа сообщения AVP для этого кадра (например, 2 для SCCRP, и 3 для SCCCN).

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

Q.931 код причины (CDN). AVP, тип атрибута 12, используется, чтобы предоставить дополнительную информацию в случае непреднамеренного разрыва соединения.
ID, присвоенное сессии (CDN, ICRP, ICRQ, OCRP, OCRQ). AVP ID, присвоенного сессии, тип атрибута 14, содержит ID, присвоенное сессии отправителем сообщения. ID, присвоенное сессии, представляет собой 2-октетное целое, ненулевое число без знака. AVP ID, присвоенного сессии, определяет код, который используется для мультиплексирования и демультиплексирования данных, посылаемых через туннель между LNS и LAC. Партнер L2TP должен поместить этот код в поле заголовка ID-сессии всех управляющих и информационных сообщений, которые пересылаются по туннелю в рамках данной сессии. До того как от партнера придет AVP ID, присвоенного сессии, управляющие сообщения должны посылаться партнеру с ID-сессии, равным нулю.
Порядковый номер вызова (ICRQ, OCRQ). AVP порядкового номера вызова, тип атрибута 15, несет в себе идентификатор, присвоенный данному вызову LAC или LNS. Порядковый номер вызова представляет собой 32-битовый код. Порядковый номер вызова предназначен для удобного административного указателя для обоих концов туннеля, когда необходимо проанализировать причину отказа. Порядковые номера вызова должны быть монотонно возрастающими числами, которые должны быть уникальными для достаточно большого периода времени для всех соединенных LNS и LAC.
Максимальный BPS (OCRQ). AVP максимального BPS, тип атрибута 16, характеризует минимальную приемлемую скорость передачи канала для данного вызова. Максимальный BPS представляет собой 32-битовый код, характеризующий скорость передачи в битах в секунду.
Максимальный BPS (OCRQ). AVP максимального BPS, тип атрибута 17, характеризует максимальную приемлемую скорость канала для данного вызова. Максимальный BPS представляет собой 32-битный код, характеризующий скорость передачи в битах в секунду.
Тип носителя (ICRQ, OCRQ). AVP типа носителя, тип атрибута 18, характеризует тип носителя для входящего или исходящего вызовов.
Тип носителя представляет собой 32-битовую маску, которая характеризует возможности несущей среды для вызова (ICRQ) или требования к среде для данного вызова (OCRQ). Если бит A=1, то вызов относится к аналоговому каналу. Если бит D=1, то вызов относится к цифровому каналу. Могут быть установлены оба бита, что может означать, что тип канала не определен, или допустима работа, как с аналоговым, так и цифровым каналами.
Тип кадрового обмена (ICCN, OCCN, OCRQ). AVP типа кадрового обмена, тип атрибута 19, характеризует тип кадров для входящих и исходящих вызовов. Тип кадрового обмена представляет собой 32-битовую маску, которая указывает тип кадрового обмена PPP, запрошенный для OCRQ, или тип кадрового обмена PPP, согласованный для OCCN или ICCN. Тип кадрового обмена может быть использован как указание PPP на LNS, какую из канальных опций использовать для согласования с LCP.
Вызванный номер (Called Number (ICRQ, OCRQ)). AVP вызванного номера, тип атрибута 21, характеризует телефонный номер, куда посылается вызов для OCRQ.
Вызывающий номер (Calling Number (ICRQ)). AVP вызывающего номера, тип атрибута 22, содержит телефонный номер входящего вызова.
Субадрес (ICRQ, OCRQ). AVP субадреса, тип атрибута 23, несет в себе дополнительную информацию по вызову. Субадрес является ASCII-строкой. Может быть, необходим контакт между администратором LAC и LNS для координации интерпретации значения, необходимого данной AVP.
Скорость канала (Tx) (Connect Speed (ICCN, OCCN)). AVP скорости канала (Tx) BPS, тип атрибута 24, характеризует быстродействие устройства, выбранного для попытки установления соединения. Скорость канала (Tx) BPS содержит 4 октета и характеризует скорость обмена в битах в секунду.
Скорость соединения Rx (Connect Speed (ICCN, OCCN)). AVP скорости соединения Rx, тип атрибута 38, представляет скорость канала с точки зрения LAC (например, информация, передаваемая от удаленной системы в LAC). BPS имеет 4 октета, характеризующие скорость обмена в битах в секунду. Присутствие этой AVP означает, что быстродействие канала может быть асимметричным с учетом скорости передачи, заданной в AVP скорости соединения Rx.
ID физического канала (ICRQ, OCRP). AVP ID физического канала, тип атрибута 25, представляет код физического канала, присвоенный ему производителем, и используемый при вызове. ID физического канала имеет 4 октета и служит только для целей регистрации.
ID частной группы (ICCN). AVP ID частной группы, тип атрибута 37, используется LAC для индикации того, что этот вызов ассоциируется с определенной группой клиентов. ID частной группы представляет собой строку октетов произвольной длины. LNS может воспринимать PPP-сессию, а также сетевой трафик в рамках сессии специальным образом, определенным партнером. Например, если LNS соединен с несколькими частными сетями, использующими незарегистрированные адреса, эта AVP может быть включена LAC, чтобы индицировать, что данный вызов должен быть ассоциирован с одной из частных сетей.
Необходима нумерация (Sequencing Required (ICCN, OCCN)). AVP Sequencing Required, тип атрибута 39, сообщает LNS, что порядковые номера должны всегда присутствовать в информационном канале. Эта AVP не имеет поля значения атрибута.

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 (ICCN). AVP последнего полученного LCP CONFREQ, тип атрибута 28, предоставляет LNS последнего CONFREQ, полученного концентратором LAC от PPP-партнера. LCP CONFREQ является копией тела последнего CONFREQ, полученного от клиента с целью завершения процедуры согласования LCP, начиная с первой опции тела LCP-сообщения.
Тип прокси 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)

Имя прокси Authen (ICCN). AVP имени прокси Authen, тип атрибута 30, специфицирует имя аутентифицируемого клиента при использовании прокси аутентификации.
Приглашение прокси Authen (ICCN). AVP приглашения прокси Authen, тип атрибута 31, специфицирует приглашение, посланное LAC партнеру PPP при использовании прокси аутентификации. Приглашение представляет собой строку из одного или более октетов.
ID прокси Authen (ICCN). AVP ID прокси Authen, тип атрибута 32, специфицирует код ID PPP-аутентификации, которая реализуется между LAC и PPP-партнером, когда используется прокси аутентификация.
Отклик прокси Authen Response (ICCN). AVP отклика прокси Authen, тип атрибута 33, специфицирует отклик аутентификации PPP, полученный LAC от PPP-партнера, когда используется прокси аутентификация. Отклик представляет собой строку октетов произвольной длины. Эта AVP должна присутствовать для типов прокси authen 1, 2, 3 и 5. Поле отклика содержит отклик клиента на приглашение. Для типов прокси authen 2 и 5, это поле содержит значение отклика, полученное LAC. Для типов 1 или 3, оно несет в себе открытый текст пароля, полученного LAC от клиента. В случае паролей с открытым текстом рекомендуется AVP-сокрытие.

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

Ошибки вызова (WEN). AVP ошибок вызова, тип атрибута 34, используется LAC для посылки LNS информации об ошибке.

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

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

ACCM (SLI). AVP ACCM, тип атрибута 35, используется LNS, чтобы проинформировать LAC о ACCM, согласуемом LNS с PPP-партнером.
Посланное ACCM и полученное ACCM имеют по 4 октета, перед которыми размещаются 2 октета зарезервированного количества. Значение посланного ACCM должно использоваться LAC для обработки пакетов, которые он отправляет через канал. Значение полученного ACCM должно использоваться LAC для обработки пакетов, которые он получает через канал. Значения по умолчанию, используемые LAC для обоих этих полей равны 0xFFFFFFFF.

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

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



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

установление контрольного соединения

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

LAC или LNS        LAC или LNS
SCCRQ ->   
                      <- SCCRP
SCCCN ->
                     <- ZLB ACK

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

аутентификация туннеля

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

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

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

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

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

LAC                 LNS
(Обнаружен вызов)
ICRQ ->
                <- ICRP
ICCN ->
                <- ZLB ACK

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

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

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

LAC                  LNS
                    <- OCRQ
OCRP ->
(Выполнить операцию вызова)
OCCN ->
                    <- ZLB ACK

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

переадресация кадров 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-туннеля.

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

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

Keepalive (Hello)

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

прерывание сессии

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

LAC или LNS            LAC или LNS
CDN ->
(Clean up)
                        <- ZLB ACK
Clean up)

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

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

LAC или LNS            LAC или LNS
StopCCN ->
(Clean up)
                        <- ZLB ACK
(Wait)
(Clean up)

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

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

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

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)

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)

Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) является управляющим сообщением, посылаемым в ответ на SCCRP. SCCCN завершает процесс установления туннеля.
Следующее AVP должно присутствовать в SCCCN: Message Type
Следующее AVP может присутствовать в SCCCN: Challenge Response

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)

Запрос входящего вызова 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)

Отклик входящего вызова 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)

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)

Запрос исходящего вызова 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.

Отклик исходящего вызова 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

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)

Call-Disconnect-Notify (CDN)
Сообщение Call-Disconnect-Notify (CDN) является L2TP управляющим сообщением, посылаемым LAC или LNS с целью запроса разрыва соединения для определенного вызова в пределах туннеля. Его целью является информирование партнера о рассоединении и причине разрыва соединения. Партнер должен освободить все ресурсы, и не посылать сообщений о причине данной операции.
Следующие AVP должны присутствовать в CDN:
— Message Type
— Код результата (Result Code)
— Assigned Session ID
Следующие AVP могут присутствовать в CDN: Код причины Q.931

WAN-Error-Notify (WEN)
Сообщение WAN-Error-Notify является L2TP управляющим сообщением, посылаемым от LAC к LNS для индикации условий ошибки WAN (условия, которые реализовались в интерфейсе, поддерживающим PPP). Счетчики в этом сообщении являются накопительными. Это сообщение должно посылаться, только когда произошла ошибка, и не чаще чем раз в 60 секунд. Счетчики сбрасываются, когда реализуется новый вызов. Следующие AVP должны присутствовать в WEN:
— Тип сообщения (Message Type)
— Ошибки вызова (Call Errors)

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

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

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

установление контрольного соединения
 

Состояние

Событие

Действие

Новое состояние

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 (ожидание управляющего отклика). Инициатор проверяет, не поступил ли запрос на установление еще одного соединения от того же самого партнера, и если это так, реагирует на столкновение.
wait-ctl-conn (ожидание управляющего соединения). Состояние, когда ожидается SCCCN; после получения, проверяется отклик приглашения. Туннель оказывается установленным, или разорванным, если не прошла аутентификация.
Established (установлено). Установленное соединение может быть аннулировано по местным причинам или в результате получения Stop-Control-Connection-Notification. В случае местного разрыва инициатор должен послать Stop-Control-Connection-Notification и ликвидировать туннель.
Если инициатор получает Stop-Control-Connection-Notification, он должен разорвать туннель.

входящие вызовы

Сообщение 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 и ликвидирует свою сессию.

состояния 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

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.

состояния 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

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. Сброс системы в базовое состояние происходит на обеих сторонах вне зависимости от действий инициатора операции.

исходящие вызовы

Исходящие вызовы инициируются 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, характеризующее окончательный результат попытки вызова.

состояния 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

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.

состояние исходящего вызова 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


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.

 

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

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

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

 

W. Townsley, A. Valencia, A., Rubens, G. Pall, G. Zorn, B. Palter, перевод Семенова Ю.А.
обсудить статью

© сетевые решения
.
.