Способы передачи РРР по Ethernet
Установление управляющего соединения
Управляющее соединение является начальным соединением, которое должно быть установлено до того, как между LAC и LNS будут установлены сессии. Установление управляющего соединения включает обеспечение безопасности идентификаций участников и т.п.
Установление управляющего соединения начинается с обмена следующими сообщениями:
ZLB ACK посылается, если в очереди нет сообщений.
Аутентификация туннеля
L2TP выполняет простую, не обязательную, СНАР-подобную аутентификацию туннеля при установлении управляющего соединения. Если LAC или LNS хочет аутентифицировать другого участника, в сообщение SCCRQ или SCCRP включается Challenge AVP. Если Challenge AVP получено, то Challenge Response AVP должен быть послан в следующем SCCRP или SCCRN соответственно. Если ответ не соответствует ожидаемому, установление туннеля должно быть сброшено.
Аутентификация выполняется с помощью разделяемого между LAC и LNS секрета. Тот же самый секрет используется для сокрытия AVP.
Установление сессии
После успешного установления управляющего соединения могут создаваться отдельные сессии. Каждая сессия соответствует одному потоку РРР между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является направленным от LAC к LNS. LAC запрашивает сессию для входящего вызова, LNS отвечает.
Установление входящего вызова
Для установления сессии используется обмен тремя сообщениями. Далее приведена типичная последовательность сообщений:
ZLB ACK посылается, если больше нет сообщений в очереди к противоположной стороне.
Установление исходящего вызова
Для установления сессии используется обмен тремя сообщениями. Далее приведена типичная последовательность сообщений:
ZLB ACK посылается, если больше нет сообщений в очереди к проти-воположной стороне.
Перенаправление РРР-кадров
После того, как завершено установление туннеля, РРР-кадры из удаленной системы получаются LAC, выполняются необходимые действия (удаление CRC, выполнение фрагментирования и т.п.), выполняется инкап-суляция в L2TP и перенаправление в соответствующий туннель. LNS получает L2TP-пакет, обрабатывает инкапсулированный РРР-кадр как если бы он был получен на локальном РРР-интерфейсе.
Отправитель сообщения, связанного с конкретной сессией и туннелем, размещает Session ID и Tunnel ID (указанные противоположной стороной) в заголовке Session ID и Tunnel ID для всех исходящих сообщений. Таким образом, РРР-кадры мультиплексируются в единственный туннель между LNS и LAC. В туннеле может существовать несколько сессий.
Нулевые значения Session ID и Tunnel ID используются для установления новой сессии.
Использование последовательных номеров в канале данных
Последовательные номера, содержащиеся в L2TP-заголовке, обяза-тельны для управляющих сообщений и не обязательны для сообщений данных. Они используются для обеспечения надежности транспорта управляющих сообщений и дополнительно могут обеспечивать подсчет сообщений данных. Каждый участник поддерживает отдельные последовательные номера для управляющего соединения и каждой отдельной сессии данных внутри туннеля.
В отличие от управляющего L2TP-канала канал данных L2TP не использует последовательные номера для повторной передачи потерянных сообщений данных. Сообщения данных могут использовать последовательные номера для определения потерянных пакетов или восстановления исходной последовательности пакетов, если при пересылке нарушена последовательность. LAC может потребовать, чтобы последовательные номера присутствовали в сообщениях данных, используя Sequencing Required AVP. Если данный AVP присутствует при установке сессии, последовательные номера должны указываться во всех сообщениях. Если данный AVP не присутствует, наличием последовательных номеров управляет LNS. Наличие или отсутствие последовательных номеров определяется посылкой сообщения с последовательным номеров в любое время в течение времени жизни сессии. Таким образом, если LAC получает сообще-ние данных без последовательного номера, он должен не посылать после-довательные номера во всех следующих исходящих сообщениях данных.
LNS может инициализировать отключение использования последовательных номеров в любой момент в течение сессии. Рекомендуется, чтобы в соединениях, в которых может происходить переупорядочение или потеря пакетов, последовательные номера всегда устанавливались при инициа-лизации РРР и отключались только в том случае, если такой риск считается приемлемым. Например, если РРР-сессия туннелируется без использования каких-либо протоколов сжатия или шифрования с поддержкой состояния, а обеспечивается просто доставка IP (как определяется установленным РРР NCP), то LNS должен отключить использование последовательных номеров, так как для IP допустимо потеря и переупорядочивание дейтаграмм.
Keepalive (Hello)
Механизм keepalive реализован в L2TP, чтобы определять отключения туннеля. Это достигается отправкой управляющих сообщений Hello через определенный период времени, прошедший после получения последнего управляющего сообщения или сообщения данных. Как и в случае любого другого управляющего сообщения, если сообщение Hello не доставлено, то туннель считается отключенным и переустанавливается. Механизм переустановки транспорта вместе со вставленными сообщениями Hello гарантирует, что разрыв соединения между LNS и LAC будет определен на обоих концах туннеля.
Завершение сессии
Завершение сессии может инициализироваться и LAC, и LNS, и состоит в посылке управляющего сообщения CDN. После того, как последняя сессия завершена, управляющее соединение может быть удалено. Типичный пример обмена сообщениями в этом случае следующий:
Завершение управляющего соединения
Завершение управляющего соединения может инициироваться и LAC, и LNS. Оно состоит в посылке единственного управляющего сообщения STOPCCN. Получатель STOPCCN должен послать ZLB ACK для подтверждения получения сообщения и поддержания состояния управляющего соединения, если ZLB ACK будет потерян. Типичный обмен сообщениями следующий:
Надежная доставка управляющих сообщений
L2TP обеспечивает надежную доставку всех управляющих сообщений. Для этого используются поля Nr и Ns в заголовке управляющего сообщения. Функции более высокого уровня в L2TP не занимаются повтором или переупорядочиванием управляющих сообщений. Каждая сторона поддерживает отдельные последовательные номера для каждого конца туннеля.
Последовательные номера управляющих сообщений возрастают на единицу. Исключением являются только ZLB-сообщений.
Номер последнего полученного сообщения передается противоположной стороне в поле Nr.
Надежность транспорта гарантирует, что управляющие сообщения получены в нужном порядке и не имеют дублей.
В каждом туннеле поддерживается очередь управляющих сообщений, которые должны быть переданы противоположной стороне. Сообщение в начале очереди посылается с текущим значением Ns и хранится до тех пор, пока противоположная сторона не подтвердит получение сообщения в поле Nr. Если подтверждение не получено в течение определенного периода времени (по умолчанию 1 секунда), сообщение передается повторно. Повторное сообщение содержит то же самое значение Ns, но значение Nr должно быть изменено на последовательный номер следующего ожидаемого сообщения.
Интервал между следующими повторными передачами должен возрастать экспоненциально. Таким образом, если первая повторная передача происходит через 1 секунду, то следующая повторная передача должна произойти через 2 секунды, затем через 4 секунды и т.д. Если противоположная сторона не отвечает после нескольких повторных передач (по умолчанию 5), то туннель и все сессии закрываются.
Если туннель удаляется по любой из причин, отличных от потери соединения, состояние и механизмы надежной доставки поддерживаются в актуальном состоянии.
Для повторной передачи управляющего сообщения используется механизм скользящего окна, аналогичный тому, который используется в ТСР.
Протокол управляющего соединения
Для установления и поддержки L2TP-туннеля используются следующие сообщения управляющего соединения.
Start-Control-Connection-Request (SCCRQ)
Управляющее сообщение SCCRQ используется для инициализации туннеля между LNS и LAC. Оно посылается либо LAC, либо LNS для установления туннеля.
В SCCRQ должны быть следующие AVP:
• Message Type AVP • Protocol Version • Host Name • Framing Capabilities • Assinged Tunnel ID
Start-Control-Connection-Reply (SCCRP)
Управляющее сообщение SCCRP посылается в ответ на получение SCCRQ сообщения. SCCRP используется для указания того, что SCCRQ получено, и установление туннеля должно продолжаться.
Start-Control-Connection-Connected (SCCCN)
Управляющее сообщение SCCCN посылается в ответ на SCCRP. Оно завершает процесс установления туннеля.
Stop-Control-Connection-Notification (STOPCCN)
Управляющее сообщение STOPCCN посылается либо LAC, либо LNS для информирования противоположной стороны о том, что туннель завершается, и управляющее соединение должно быть закрыто. Кроме того, все управляющие сессии должны быть неявно очищены (без посылки каких-либо управляющих сообщений). Причина данного запроса указана в Result Code AVP. На данное сообщение нет явного ответа, только неявное подтверждение на транспортном уровне, что получено управляющее сообщение.
Hello
Сообщение Hello периодически посылается любым из участников для подтверждения жизнеспособности ("keepalive") туннеля.
Надежность доставки этого сообщения гарантируется лежащим ниже транспортом.
Сообщения Hello являются глобальными для туннеля. Session ID в сообщении Hello установлено в 0.
Incoming-Call-Request (ICRQ)
Управляющее сообщение ICRQ посылается от LAC к LNS, когда определен входящий вызов. Это первое из трех сообщений, которые используются для установления сессии в L2TP-туннеле.
ICRQ используется для указания того, что для данного вызова устанавливается сессия между LAC и LNS и предоставляет LNS-параметры сессии. LAC может отложить ответ на вызов до тех пор, пока он не получит ICRQ от LNS, указывающее, что сессия должна быть установлена. Данный механизм позволяет LNS получать информацию о вызове до определения того, нужно ли на него отвечать или нет. В качестве альтернативы LAC может ответить на вызов, начать переговоры об LCP и РРР-аутентификации и использовать информацию, полученную для выбора LNS. В этом случае при получении сообщения ICRP на вызов уже будет дан ответ. LAC просто игнорирует шаги "индикация вызова" и "ответ вызова".
Incoming-Call-Reply (ICRP)
Управляющее сообщение ICRP посылается от LNS к LAC в ответ на получение сообщения ICRQ. Это второе из трех сообщений, используемых для установления сессий в L2TP-туннеле.
ICRP используется для указания того, что ICRQ было успешным и для того, чтобы LAC ответил на вызов, если он еще не сделал этого. Это также позволяет LNS указать необходимые параметры L2TP-сессии.
Incoming-Call-Connection (ICCN)
Управляющее сообщение ICCN посылается от LAC к LNS в ответ на получение сообщения ICRР. Это третье из трех сообщений, используемых для установления сессий в L2TP-туннеле.
ICCN используется для указания того, что ICRP получено, на вызов был дан ответ, и что L2TP-сессия находится в состоянии "установлено". Оно также предоставляет LNS дополнительную информацию об используемых параметрах, которые еще могли быть не доступны при посылке сообщения ICRQ.
Outgoing-Call-Request (OCRQ)
Управляющее сообщение OCRQ посылается от LNS к LAC для указания того, что исходящий вызов от LAC установлен. Это первое из трех сообщений, используемых для установления сессии в L2TP-туннеле.
OCRQ используется для указания того, что для данного вызова сессия между LNS и LAC установлена.
LNS при установлении туннеля получает от LAC Bearer Capabilities AVP, чтобы запросить исходящий вызов к данному LAC.
Outgoing-Call-Reply (OCRP)
Управляющее сообщение OCRP посылается от LAC к LNS в ответ на получение сообщения OCRQ. Это второе из трех сообщений, используемых для установления сессии в L2TP-туннеле.
OCRP используется для указания того, что LAC пытается установить исходящий вызов, и возвращает соответствующие параметры.
Outgoing-Call-Connection (OCCN)
Управляющее сообщение OCCN посылается от LAC к LNS после OCRP и после того, как исходящий вызов завершен. Это заключительное сообщение из трех сообщений, используемых для установления сессии в L2TP-туннеле.
OCCN используется для указания того, что запрошенный исходящий вызов был успешным. В этом сообщении также указывается информация для LNS параметрах, полученных после установления вызова.
Call-Disconnect-Notify (CDN)
Управляющее сообщение CDN посылается либо LAC, либо LNS для запроса разрыва соединения внутри туннеля. Его цель состоит в информировании противоположной стороны о разрыве соединения и о причине этого разрыва. Противоположная сторона очищает все ресурсы и не посылает никакого ответного уведомления.
WAN-Error-Notify (WEN)
Управляющее сообщение WEN посылается от LAC к LNS для указания об условиях ошибки WAN (условиях, которые произошли на интерфейсе, поддерживающим РРР).
Set-Link-Info (SLI)
Управляющее сообщение SLI посылается от LNS к LAC для установления РРР-опций. Эти опции могут быть изменены в течение всего времени жизни соединения, тем самым LAC имеет возможность изменить свою информацию и поведение РРР-сессии.
Состояния управляющего соединения
Описанными выше управляющими сообщениями обмениваются приведенным в таблицах способом. Таблицы определены для входящих и исходящих вызовов, а также для инициализации самого туннеля. В таблицах состояний не определены таймауты и поведение при повторных передачах.
Рассмотрим операции, выполняемые различными функциями управля-ющего соединения L2TP и сообщения, которые при этом используются.
Протокол управляющего соединения не делает различая между LNS и LAC, но делает различие между отправителем и получателем. Туннель инициирует отправитель. Так как и LAC, и LNS могут быть отправителями, может возникнуть коллизия.
Установление управляющего соединения
Состояниями, связанными с LNS или LAC для установленного управляющего соединения, являются: