Примеры сетевых топологий
Надежная доставка управляющих сообщений
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 представлены примеры управляющих сообщений, подтверждений и повторных передач.
