Технологии LRE и xDSL : PPPoE/PPPoA (PPP over Ethernet / PPP over ATM)

Базовая архитектура PPPoA

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ описывает архитектуру ADSL с использованием протокола PPP поверх ATM (PPPoA). Несмотря на то, что общепринятая практика развертывания опирается на архитектуру с использованием мостов, PPPoA обретает феноменальную популярность и в перспективе станет наиболее часто применяемым вариантом ADSL.

Предположение

Базовая архитектура принимает потребность в обеспечении высокоскоростного доступа к Интернету и корпоративного доступа до конца абонент, использующий PPPoA в качестве центральной магистрали сети. Мы обсудим эту архитектуру на основе частных виртуальных каналов (PVCs), метод, используемый чаще всего в текущих развертываниях. Архитектура с помощью коммутируемых виртуальных каналов (SVC) будет обсуждена в отдельной статье.

Этот документ основывается на существующих развертываниях, а также встроенных проверках архитектуры.

Этот документ был записан учитывая, что читатель хорошо осведомлен и знаком с вопросами проектирования Network Access Provider (NAP), как описано в Описании технологических решений Базовой архитектуры моста RFC1483.

Технологическое Краткое описание

Протокол PPP (RFC 1331) предоставляет стандартный метод инкапсуляции протоколов высшего уровня через двухточечные соединения. Это расширяет структуру пакета High-Level Data Link Control (HDLC) с помощью 16-разрядного идентификатора протокола, который содержит информацию о содержании пакета.

Пакет содержит три типа информации:

  • Протокол управления каналом (LCP) – выполняет согласование о параметрах ссылки, размере пакета или типе аутентификации

  • Протокол управления сетью (NCP) – содержит информацию о протоколах высшего уровня включая IP и IPX и их протоколы управления (IPCP для IP)

  • Фреймы данных, содержащие данные

Уровень адаптации PPP over ATM 5 (AAL5) (RFC 2364) использует AAL5 в качестве фреймированного протокола, который поддерживает и PVC и SVC. PPPoA был прежде всего внедрен как часть ADSL. Это полагается на RFC1483, работающий или в Протоколе доступа к подсети управления логическим Каналом (LLC) (LLC-SNAP) или в Режиме мультиплексора VC. Устройство Customer Premises Equipment (CPE) инкапсулирует сеанс PPP на основе этого RFC для транспорта через петлю ADSL и мультиплексора доступа к цифровой абонентской линии (DSLAM) (DSLAM).

Преимущества и недостатки архитектуры PPPoA

Архитектура PPPoA наследовала большинство преимуществ PPP, используемых в Набираемой модели. Некоторые ключевые точки упомянуты ниже.

Преимущества

  • На проверку подлинности для сеанса на основе Протокола аутентификации пароля (PAP) или Протокола аутентификации по квитированию вызова (CHAP). Это - самое большое преимущество PPPoA, поскольку аутентификация преодолевает брешь системы безопасности в архитектуре с использованием мостов.

  • На сеанс учет возможен, который позволяет поставщику услуг обвинять абонента на основе времени сеанса для различных предложенных услуг. На сеанс учет позволяет поставщику услуг предложить минимальный уровень доступа для минимальной оплаты и затем обвинить абонентов за используемые дополнительные сервисы.

  • Сохранение IP-адреса в CPE. Это позволяет поставщику услуг назначать только один IP-адрес для CPE с CPE, настроенным для технологии NAT. Все пользователи позади одного CPE могут использовать один IP-адрес для достижения других назначений. Издержки IP - управления для Network Access Provider/Network Services Provider (NAP/NSP) для каждого отдельного пользователя уменьшены при сохранении IP-адресов. Кроме того, поставщик услуг может предоставить маленькую подсеть IP-адресов для преодоления ограничений преобразования адресов портов (PAT) и NAT.

  • NAP/NSP предоставляют безопасный доступ корпоративным шлюзам, не управляя сквозным PVCs и с помощью маршрутизации Уровня 3 или Протокола туннелирования Передачи/Уровня 2 Уровня 2 (L2F/L2TP) туннели. Следовательно, они могут масштабировать свой бизнес - модели для продажи крупномасштабных сервисов.

  • Устранение проблем отдельных подписчиков. NSP может легко определить, какие абоненты идут или прочь на основе активных сеансов PPP, вместо того, чтобы устранить неполадки всех групп, как имеет место с архитектурой с использованием мостов.

  • NSP может превысить намеченную сумму путем развертывания времен ожидания простоя и сеанса с помощью сервера Cервиса RADIUS промышленного стандарта для каждого абонента.

  • Хорошо масштабируемый, поскольку мы можем завершить очень большое число сеансов PPP на маршрутизаторе с поддержкой агрегирования. Аутентификация, авторизация и учет может быть обработана для каждого пользователя, использующего внешние серверы RADIUS.

  • Оптимальное использование функций на Шлюзе выбора сервиса.

Недостатки

  • Только одиночный сеанс на CPE на одном virtual channel (VC). Начиная с имени пользователя и пароля настроены на CPE, всех пользователях позади CPE, для которого определенный VC может обратиться только к одному набору сервисов. Пользователи не могут выбрать другие наборы сервисов, невзирая на то, что использование множественных VC и установление других сеансов PPP на других VC возможны.

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

  • Поставщик услуг должен поддержать базу данных имен пользователя и паролей для всех абонентов. Если туннели или сервисы proxy используются, то аутентификация может быть сделана на основе доменного имени, и проверка подлинности пользователя сделана в корпоративном шлюзе. Это уменьшает размер базы данных, которую должен поддержать поставщик услуг.

  • Если один IP-адрес будет предоставлен CPE, и NAT/PAT внедрен, определенные приложения, такие как IPTV, которые встраивают IP - информацию в информационное наполнение, то не будет работать. Кроме того, если функция IP-подсети использована, IP-адрес также должен быть зарезервирован для CPE.

Принципы реализации архитектуры PPPoA

Ключевые точки для рассмотрения прежде, чем внедрить архитектуру PPPoA включают:

  • Количество абонентов, которые будут обслуживаться в настоящее время и в будущем, поскольку это влияет на количество требуемых сеансов PPP.

  • Завершаются ли сеансы PPP в поставщике услуг? s маршрутизатор с поддержкой агрегирования или переданный другим корпоративным шлюзам или интернет-провайдерам (интернет-провайдеры).

  • Предоставляют ли поставщик услуг или окончательное назначение сервиса IP-адрес абоненту? s CPE.

  • Являются ли предоставленные IP-адреса допустимыми общедоступный или частными. Переходит CPE, делают NAT/PAT или NAT будут выполнены в конечном месте прекращения?

  • Профили абонентов, индивидуальных пользователей, клиентов Small Office Home Office (SOHO) и дистанционных пользователей компьютера.

  • В случае нескольких пользователей, должны ли все пользователи достигнуть того же конечного назначения или сервиса, или у них всех есть другие служебные назначения.

  • Поставщик услуг предоставляет какие-либо дополнительные услуги как голос или видео? Поставщик услуг требует, чтобы все абоненты сначала перешли к индивидуальной сети прежде, чем достигнуть конечного назначения? Когда абоненты используют SSG, они переходят к сервисам passthrough использования, PPP Terminated Aggregation (PTA), посредническому устройству или прокси?

  • Как используются абоненты счетов поставщика услуг — на основе фиксированной ставки, на использование за сеанс или сервисы.

  • Развертывания и инициализация CPE, DSLAMs и точек агрегации присутствия (POP).

  • Бизнес - модель для NAP. Модель также включает продажу крупномасштабных сервисов как безопасный корпоративный доступ и дополнительных услуг как голос и видео? Действительно ли NAP и NSP являются тем же объектом?

  • Бизнес - модель компании. Действительно ли это сопоставимо с независимой местной телефонной компанией (ILEC), альтернативным оператором местной связи (CLEC) или интернет-провайдером?

  • Типы приложений NSP предложат до конца абоненту.

  • Ожидаемый восходящий и нисходящий объем потока данных.

Помня эти точки, мы обсудим, как архитектура PPPoA будет соответствовать и масштабироваться к другому бизнесу - моделям для поставщиков услуг и как поставщики могут принести пользу использованию этой архитектуры.

Архитектура типичной сети PPPoA

Следующая схема показывает типичную Архитектуру сети на основе протокола PPPoA. Клиенты, использующие CPE, соединяются с сетью поставщика услуг через DSLAM Cisco, который соединяется с агрегатором Cisco 6400 с помощью ATM.

/image/gif/paws/12914/pppoa_arch_1.gif

Принципы проектирования архитектуры PPPoA

В разделе "Вопросов внедрения" этого документа архитектуры PPPoA могут быть развернуты с помощью других сценариев в зависимости от поставщика услуг? s бизнес - модель. В этом разделе мы обсудим другие возможности и факторы, которые поставщики услуг должны иметь в виду прежде, чем развернуть решение.

Прежде, чем развернуть архитектуру PPPoA и конкретное решение для этой архитектуры, важно понять поставщика услуг? s бизнес - модель. Рассмотрите услуги, которые предложит поставщик услуг. Поставщик услуг предложит одну услугу как высокоскоростной доступ к Интернету ее абонентам, или это продаст крупномасштабные сервисы другим интернет-провайдерам и предоставит дополнительные сервисы тем абонентам? Поставщик услуг предложит всем им?

В случае высокоскоростного доступа к Интернету в среде, где NSP и NAP являются тем же, абонентом? s сеансы PPP должен быть завершен в развернутом маршрутизаторе с поддержкой агрегирования. В этом сценарии поставщики услуг должны рассмотреть, сколько сеансов PPP может быть завершено на устройстве агрегации одиночного маршрутизатора, как пользователи собираются быть аутентифицируемыми, как они переходят, выполняют учет и путь к Интернету, как только завершены пользовательские сеансы. В зависимости от количества сеансов PPP и абонентов, маршрутизатор с поддержкой агрегирования мог быть или Cisco 6400 или Cisco 7200. Сегодня? s Cisco 6400 с 7 переработчиками маршрута узла (NRP) может завершить до 14,000 сеансов PPP. Cisco 7200 ограничен 2,000 сеансов PPP. Эти номера изменятся с новыми версиями. Проверьте Комментарии к выпуску и документации по продукту для точного номера сеансов, которые может поддержать каждый маршрутизатор с поддержкой агрегирования.

Проверка подлинности пользователя и считающий в них, сценарий лучше всего обрабатывается при помощи сервера RADIUS промышленного стандарта, который может аутентифицировать пользователя на основе имени пользователя или идентификатора виртуального тракта/виртуальный идентификатор канала используемый (VPI/VCI).

Для высокоскоростного доступа к Интернету, NSP обычно клиенты счета фиксированная ставка. Большинство текущих развертываний внедряется этот путь. Когда NSP и NAP являются тем же объектом, клиенты тарифицированы в фиксированной скорости передачи за доступ и другой фиксированной скорости передачи для доступа в Интернет. Когда поставщик услуг начинает предлагать дополнительные сервисы, эта модель изменяется. Поставщики услуг могут обвинить клиента на основе типа сервиса и продолжительности, сервис используется. Клиенты соединяются с Интернетом через маршрутизатор с поддержкой агрегирования с помощью протоколов маршрутизации как Протокол OSPF или Протокол EIGRP к краевому маршрутизатору, который мог выполнять Протокол BGP.

Другая опция, которую поставщик услуг имеет для обеспечения высокоскоростного доступа к Интернету, должна передать входящие сеансы PPP от абонентов к отдельному интернет-провайдеру с помощью Туннелирования L2TP/L2F. Когда Туннелирование L2x используется, специальные вопросы должны быть даны для того, как может быть достигнуто назначение туннеля. Доступные параметры состоят в том, чтобы или выполнить некоторые протоколы маршрутизации или предоставить статические маршруты в маршрутизаторе с поддержкой агрегирования. Ограничения при использовании L2TP или туннелей L2F: (1) количество туннелей и количество сеансов, которые могут поддерживаться в тех туннелях; и (2) использование протоколов маршрутизации, несовместимых с интернет-провайдерами третьей стороны, которые могут потребовать статических маршрутов использования.

Если поставщик услуг предлагает услуги для других интернет-провайдеров или корпоративных шлюзов до конца абонент, они, возможно, должны реализовать опции SSG на маршрутизаторе с поддержкой агрегирования. Это позволяет абоненту выбирать другие служебные назначения при помощи Выбора сервиса на основе веб. Поставщик услуг может или передать сеансы PPP абонентов их выбранным назначениям путем объединения всех сеансов, предназначенных к интернет-провайдеру в одиночный PVC для транспорта, или если поставщик услуг предлагает уровни множественного обслуживания, несколько PVC могли бы быть установлены через ядро.

В модели массового обслуживания поставщик услуг может не использовать функции SSG. В этой модели поставщик услуг расширяет все сеансы PPP до домашних шлюзов. Домашние шлюзы предоставляют IP-адреса до конца абонент и аутентифицируют конечного пользователя.

Основное рассмотрение в любом из этих сценариев состоит в том, как поставщик услуг может предложить другое Качество обслуживания (QoS) для других сервисов и как они вычисляют распределение пропускной способности. В настоящее время способ, которым большинство поставщиков услуг развертывает эту архитектуру, предлагает другое QoS на другом PVCs. У них может быть отдельный PVCs на ядре для индивидуальных и коммерческих клиентов. Использование другого PVCs позволяет поставщикам услуг задавать другое QoS для других сервисов. Таким образом, QoS могло идти отдельный PVCs или на Уровне 3.

Применение QoS на Уровне 3 требует, чтобы поставщик услуг знал конечное назначение, которое могло быть ограничивающим фактором. Но, если используется в сочетании с QoS Уровня 2 (путем применения его на другие VC), это может быть полезно для поставщика услуг. Ограничение с этой моделью - то, что она исправлена, и поставщик услуг должен настроить для QoS заранее. QoS не становится прикладным динамично на выборе сервиса. В настоящее время нет никакой опции для пользователя для выбора других пропускных способностей для других сервисов щелчком мыши; однако, значительную опытно-конструкторскую работу инвестировали для разработки этой функции.

Развертывание CPE, управление и инициализация могли быть очень стимулирующими в этой архитектуре, поскольку CPE должен быть настроен для имен пользователя и паролей. Как простое решение, некоторые поставщики услуг используют то же имя пользователя и пароль для всех CPE. Это представляет значительную угрозу безопасности. Кроме того, если CPE должен одновременно открыть другие сеансы, дополнительные VC должны быть настроены в CPE, NAP и NSP. Cisco DSLAMs и устройства агрегации имеет способность упростить конфигурацию CPE и инициализацию. Средства управления flow-through также доступны для сквозной Инициализации PVC. Инициализация в NSP для такого количества абонентов, использующих PVCs, является ограничивающим фактором, так как нужно управлять всем другим PVCs. Кроме того, нет никакого простого пути настроить 2000 PVCs на одиночном NRP путем щелчка мышью или ввода немногих нажатий клавиш.

Сегодня у нас есть другие приложения управления сетью для других компонентов этой архитектуры, таких как Viewrunner для DSLAM и SCM для Cisco 6400 нет никакой единой платформы управления, которая настроит все компоненты. Это - хорошо распознанное ограничение, и большое усилие инвестируют для имения одиночного, приложения комплексного управления для инициализации CPE, DSLAM и Cisco 6400. Кроме того, у нас в настоящее время есть решение внедрить PPPoA с SVC, который значительно упростит развертывания. PPPoA с SVC также позволит конечным пользователям выбирать назначение и QoS динамично.

Другой важный момент для учета для больших развертываний ADSL с помощью этой архитектуры является связью от маршрутизатора с поддержкой агрегирования до сервера RADIUS. Если уровень NRP отказывает, когда несколько тысяч сеансов PPP завершены на устройстве агрегации, все те сеансы PPP должны быть восстановлены. Это означает, что все абоненты должны аутентифицироваться, и их учетные записи остановили и перезапустили, как только установлено соединение. Когда столько абонентов пытается аутентифицироваться в то же время, канал к серверу RADIUS может быть узким местом. Некоторые абоненты могут не быть в состоянии аутентифицироваться, и это может создать проблемы для поставщика услуг.

Очень важно иметь ссылку на сервер RADIUS с достаточной пропускной способностью для размещения всех абонентов в то же время. Кроме того, сервер RADIUS должен быть достаточно мощным для давания разрешений всем абонентам. В случае тысяч абонентов нужно рассмотреть опцию для распределения нагрузки между доступными серверами RADIUS. Эта функция доступна в Cisco программное обеспечение IOS�.

Как последний вопрос, маршрутизатор с поддержкой агрегирования должен выполнить достаточно для размещения многих сеансов PPP. Примените те же принципы регулирования трафика, используемые другими реализациями. Ранее, пользователь должен был настроить PVCs на подчиненных интерфейс типа точка-точка. Сегодня PPPoA позволяет пользователям настраивать множественный PVCs на многоточечных подчиненных интерфейс, а также точка-точка. Каждое соединение PPPoA больше не требует двух Interface Descriptor Block (IDB), один для интерфейса виртуального доступа и один для подчиненного интерфейс ATM. Это усовершенствование увеличивает максимальное число Сеансов PPPoA, работающих на маршрутизаторе.

Сеансы PPPoA максимального числа, поддерживаемые на платформе, зависят от ресурсов доступной системы, таких как память и скорость ЦП. Каждый Сеанс PPPoA берет один интерфейс виртуального доступа. Каждый интерфейс виртуального доступа состоит из блока дескриптора интерфейса оборудования и блока дескриптора программного интерфейса (hwidb/swidb) пара. Каждый hwidb сопровождает 4.5K. Каждый swidb сопровождает 2.5K. Вместе, интерфейсы виртуального доступа требуют 7.5K. 2000 интерфейсов виртуального доступа требуют 2000 * 7.5K или 15M. Для выполнения 2000 сеансов маршрутизатору нужно дополнительное 15M. Из-за увеличения предела сеанса маршрутизатор должен поддержать больше IDB. Эта поддержка влияет на производительность в связи с к большему количеству циклов ЦПУ для выполнения большего количества экземпляров механизма состояний PPP.

Основные особенности архитектуры PPPoA

В этом разделе описываются три ключевых точки в архитектуре PPPoA: CPE, IP - управление и достижение служебного назначения.

/image/gif/paws/12914/pppoa_arch_2.gif

Из-за природы PAT, определенные приложения, которые встраивают IP - информацию в информационное наполнение, не могут работать в этом сценарии. Для решения этой проблемы примените подсеть IP-адресов, а не одного IP-адреса.

В этой архитектуре для NAP/NSP к Telnet в CPE легче настроить и устранить неполадки, так как IP-адрес назначен на CPE.

CPE могут использовать различные варианты в зависимости от абонента? s профиль. Например, для индивидуального пользователя CPE может быть настроен без PAT/DHCP. Для абонентов с несколькими ПК CPE могут быть настроены или для PAT/DHCP или для того же пути как тот из индивидуального пользователя. Если существует IP-телефон, связанный с CPE, CPE может быть настроен для нескольких PVC.

Управление системами IP

pppoa_arch_3.gif

В архитектуре PPPoA IP - адрес размещения для CPE абонента использует согласование IPCP, тот же принцип PPP в режиме набора. IP-адреса выделены в зависимости от типа сервиса, который использует абонент. Если у абонента будет только доступ в Интернет от NSP, то NSP завершит те сеансы PPP от абонента и назначит IP-адрес. IP-адрес выделен от локально определенного пула, сервера DHCP, или может быть применен от сервера RADIUS. Кроме того, интернет-провайдер, возможно, предоставил ряд статических IP - адресов абоненту и может не назначить IP-адреса динамично, когда абонент инициирует сеанс PPP. В этом сценарии поставщик услуг будет использовать только сервер RADIUS для аутентификации пользователя.

Если абонент предпочитает иметь множественное обслуживание в наличии, NSP, возможно, должен внедрить SSG. Придерживающееся является возможностями для присвоения IP-адресов.

  • SP может предоставить IP-адрес абоненту через его локальный пул или сервер RADIUS. После того, как пользователь выбирает сервис, SSG вперед пользователь? s трафик тому назначению. Если SSG использует режим proxy, конечное назначение может предоставить IP-адрес, который SSG будет использовать в качестве видимого адреса для NAT.

  • Сеансы PPP не становятся завершенными на поставщике услуг? s маршрутизатор с поддержкой агрегирования. Они или туннелированы или переданы конечному назначению или домашнему шлюзу, который в конечном счете завершит сеансы PPP. Конечное назначение или домашний шлюз выполняют согласование о IPCP с абонентом, таким образом предоставляя IP-адрес динамично. Статические адреса также возможны, пока конечное назначение выделило те IP-адреса и имеет маршрут им.

До Cisco IOS Software Release 12.0.5DC для Cisco NRP серии 6400, не было никакого способа для поставщика услуг предоставить подсеть IP-адресов абоненту. Платформа Cisco 6400 и серии CPE Cisco 600 позволяют IP-подсетям быть динамично настроенными на CPE во время согласования PPP. Один IP-адрес от этой подсети назначен на CPE, и оставшиеся IP - адреса динамично выделены станциям через DHCP. Когда эта функция использована, CPE не должны быть настроены для PAT, который не работает с некоторыми приложениями.

Как достигается конечный адрес службы

В архитектурах PPPoA служебное назначение может быть достигнуто по-разному. Некоторые обычно развернутые методы:

  • Завершение сеансов PPP в поставщике услуг

  • Туннелирование L2TP

  • Использование SSG

Во всех трех методах существует неподвижный набор PVCs, определенного от CPE до DSLAM, который коммутирован к закрепленному набору PVCs на маршрутизаторе с поддержкой агрегирования. PVCs сопоставлены от DSLAM до маршрутизатора с поддержкой агрегирования через облако ATM.

Служебное назначение может также быть достигнуто с помощью других методов такой PPPoA с SVC или Многопротокольная коммутация по меткам/виртуальная частная сеть. Эти методы выходят за рамки этого документа и будут обсуждены в отдельных статьях.

Завершение PPP в агрегации

pppoa_arch_4.gif

Сеансы PPP, инициируемые абонентом, завершены в поставщике услуг, который аутентифицирует пользователей, использующих или локальную базу данных на маршрутизаторе или через серверы RADIUS. После того, как пользователь аутентифицируется, согласование IPCP имеет место, и IP-адрес назначен на CPE. После того, как IP-адрес был назначен, существует маршрут хоста, установленный и на CPE и на маршрутизаторе с поддержкой агрегирования. IP-адреса, выделенные абоненту, если законный, объявлены к краевому маршрутизатору. Краевой маршрутизатор является шлюзом, через который абонент может обратиться к Интернету. Если IP-адреса являются частными, поставщик услуг преобразовывает их прежде, чем объявить их к краевому маршрутизатору.

Туннелирование L2TP/L2F

pppoa_arch_5.gif

Сеансы PPP, в зависимости от поставщика услуг или корпорации, туннелируйте к восходящей оконечной точке соединения с помощью L2TP или L2F вместо того, чтобы быть завершенными на поставщике услуг? s маршрутизатор с поддержкой агрегирования. Эта оконечная точка соединения аутентифицирует имя пользователя, и абоненту назначают IP-адрес через DHCP или локальный пул. Для этого сценария обычно существует один туннель, установленный между Концентратором доступа L2TP / сервер доступа к сети (LAC/NAS) и домашним шлюзом или L2TP Network Server (LNS). LAC аутентифицирует сеанс входа на основе доменного имени; имя пользователя аутентифицируется в конечном назначении или домашнем шлюзе.

В этой модели, однако, пользователь может только иметь доступ к конечному назначению и может обратиться только к одному назначению за один раз. Например, если CPE настроен с именем пользователя rtr@cisco.com, PC, позади которых CPE может только иметь доступ к домену Cisco. Если они хотят соединиться с другой корпоративной сетью, они должны изменить имя пользователя и пароль на CPE, чтобы отразить что корпоративное доменное имя. Назначение туннеля в этом случае достигнуто при помощи протокола маршрутизации, статических маршрутов или выполнения классического IP по ATM (если ATM предпочтен как Уровень 2).

Использование шлюза выбора сервиса

/image/gif/paws/12914/pppoa_arch_6.gif

Основное преимущество SSG по туннелированию - то, что SSG предоставляет сопоставление сервисов один ко многим, тогда как туннелирование предоставляет только однозначное сопоставление. Когда одиночный пользователь должен обратиться ко множественному обслуживанию или нескольким пользователей в одиночном местоположении каждый доступ потребности к уникальному сервису, это становится очень полезным. SSG использует Информационную панель Выбора сервиса на основе веб (SSD), который состоит из других сервисов и доступен пользователю. Пользователь может обратиться к одному сервису или множественному обслуживанию когда-то. Другое преимущество использования SSG состоит в том, что поставщик услуг может тарифицировать пользователя на основе используемых сервисов и время сеанса, и пользователь может включить и выключить сервисы через SSD.

/image/gif/paws/12914/pppoa_arch_7.gif

Пользователи аутентифицируются, поскольку сеанс PPP входит от абонентов. Пользователи являются назначенными IP - адресами или от локального пула или от сервера RADIUS. После того, как пользователь успешно аутентифицируется, исходный объект создан кодом SSG, и пользователю предоставляют доступ к сети по умолчанию. Сеть по умолчанию содержит сервер SSD. Использование браузера, входов пользователя в систему в к Информационной панели, аутентифицируется AAA-сервером, и в зависимости от пользователя? s профиль, сохраненный в сервере RADIUS, предложенный ряд услуг для доступа.

Каждый раз, когда проверенный пользователь выбирает сервис, SSG создает объект назначения для того пользователя. Объект назначения содержит информацию, такую как адрес назначения (DA), адрес сервера DNS для того назначения и назначенный IP - адрес источника от домашнего шлюза. Пакеты, входящие от пользователя? s сторона переданы назначению на основе информации, содержавшейся в объекте назначения.

SSG может быть настроен для сервиса proxy, прозрачной транзитной пересылки или ПТА. Когда абонент запросит доступ к сервису proxy, NRP-SSG передаст access-request к удаленному серверу RADIUS. После получения access-accept SSG отвечает абоненту с access-accept. SSG появляется как клиент к удаленному серверу RADIUS.

Прозрачная транзитная пересылка позволяет не прошедшему поверку подлинности трафику абонента маршрутизироваться через SSG в любом направлении. Используйте фильтры для управления трафиком прозрачной транзитной пересылки.

ПТА может только использоваться пользователями типа PPP. Аутентификация, авторизация и учет выполнена точно как в типе сервиса proxy. Абонент входит к сервису с помощью имени пользователя формы user@service. SSG вперед, что к серверу RADIUS, который тогда загружает профиль сервиса в SSG. SSG пересылает запрос на удаленный сервер RADIUS, как задано профилем сервиса? s атрибут сервера RADIUS. После того, как запрос аутентифицируется, IP-адрес назначен на абонента. Никакой NAT не выполнен. Весь трафик пользователя объединен к удаленной сети. С ПТА пользователи могут обратиться только к одному сервису и не будут иметь доступа к сети по умолчанию или SSD.

Эксплуатационное описание архитектуры PPPoA

Когда CPE сначала включен, он начинает передавать запросы конфигурации LCP к серверу агрегации. Сервер агрегации, с настроенным PVCs, также отсылает запрос конфигурации LCP на Интерфейсе виртуального доступа (привязанный к PVC). Когда каждый видит запрос конфигурации другого, они подтверждают запросы, и состояние LCP открыто.

Для этапа аутентификации CPE передает запрос аутентификации к серверу агрегации. Сервер, в зависимости от его конфигурации, любой аутентифицирует пользователя на основе доменного имени (если предоставлено), или имя пользователя с помощью его локальной базы данных или серверов RADIUS. Если запрос от абонента будет в форме username@domainname, то сервер агрегации попытается создать туннель назначению, если вы уже не будете там. После того, как туннель создан, сервер агрегации передает запросы PPP от абонента назначению. Назначение, в свою очередь, аутентифицирует пользователя и назначает IP-адрес. Если запрос от абонента не включает доменное имя, пользователь аутентифицируется локальной базой данных. Если SSG настроен на маршрутизаторе с поддержкой агрегирования, пользователь может обратиться к сети по умолчанию, как задано и может заставить опцию выбирать другие сервисы.

Заключение

PPPoA становится большей частью подходящей архитектуры для многих поставщиков услуг, потому что это является хорошо масштабируемым, использует функциональные возможности SSG и предоставляет безопасность. Так как фокусом этой бумаги была архитектура PPPoA, не было возможно покрыть функции как SSG подробно. Эти функции будут охвачены в последующих бумагах. Примеры конфигурации для других сценариев, обсужденных в этом документе, будут также представлены и объяснены в отдельных статьях.


Дополнительные сведения


Document ID: 12914