Примеры сетевых топологий
определяет механизм инкапсуляции для транспортировки
Протокол 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.
Протокол сетевого времени (NTP v3), описанный в документе RFC-1305 [MIL92], широко используется для синхронизации часов ЭВМ в глобальном Интернет. Он обеспечивает доступ к национальным системам точного времени. В большинстве мест Интернет протокол гарантирует точность синхронизации с точностью 1-50 мс, в зависимости от свойств источника синхронизации и сетевых задержек.
RFC-1305 специфицирует машину протокола NTP v3 в терминах событий, состояний, функций перехода и действий. Кроме того, там определены инженерные алгоритмы улучшения точности синхронизации и выбора из списка эталонных источников, некоторые из которых могут быть неисправны. Эти алгоритмы необходимы для компенсации влияния вариаций задержки пакетов в сети Интернет. Однако, во многих обстоятельствах приемлемы точности порядка доли секунды. В таких случаях используется более простые протоколы времени [POS83]. Эти протоколы обычно использует RPC-обмен, где клиент запрашивает время дня, а сервер присылает его значение в секундах после некоторого известного эталонного момента.
NTP создан для использования клиентами и серверами с широким диапазоном возможностей для широкого интервала сетевых задержек и большого временного разброса. Большинство пользователей NTP синхронизации используют программное обеспечение с полным набором опций и алгоритмов (смотри ).
SNTP v 4 предполагает совместимость с NTP и SNTP v 3 как для клиентов так и для серверов. Кроме того, клиенты и серверы SNTP v.4 могут реализовывать расширения для работы в эникаст режиме.
Клиенты SNTP должны работать только на самом верхнем уровне субсети в конфигурациях, где синхронизация NTP или SNTP клиентов не зависит от других клиентов. Серверы SNTP должны работать только на первом (базовом) уровне субсети и в конфигурациях, где нет других источников синхронизации кроме надежных радио или модемных служб точного времени.
