Стек Протоколов PPP(Point-to-Point Protocol)

2.3. Предотвращение зацикливания протокола РРР

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

2.4. Протокол качества

На некоторых линиях связи требуется определять, когда и как часто канал теряет данные. Этот процесс называется контролем качества канала связи. Существует опция конфигурации, которая обеспечивает согласование типа протокола качества (QP - Quality-Protocol) канала связи. По умолчанию контроль качества связи не осуществляется.

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

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

Формат опции конфигурации протокола качества показан ниже. Поля передаются слева направо.

Поле "Тип"

Имеет значение, равное 4.

Поле "Длина"

Не менее 4 октетов.

Поле "Протокол качества "

Поле "Протокол качества" содержит два октета и указывает желательный протокол, контролирующий качество связи. Значения этого поля - всегда те же, что и в поле протокола PPP для того тот же самого протокола контроля. ("Assigned Numbers" RFC, последний выпуск)

Текущие значения определены следующим образом:

Поле "Данные"

Поле "Данные" включает нуль или более октетов и содержит дополнительные данные, как определено соответствующим специальным протоколом.

2.5. Сжатие поля протокола

Эта опция конфигурации обеспечивает метод согласования сжатия полей протокола PPP (PFC - Protocol-Field-Compression). По умолчанию все приложения должны передать пакеты с двухоктетными полями протокола PPP.

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

Поле протокола использует механизм расширения, соответствующий механизму расширения ISO 3309 для полей адреса; наименее значащий бит (LSB - Least Significant Bit) каждого октета используется для указания на расширение поля протокола. Двоичный "0" в качестве LSB указывает, что поле протокола будет продолжаться в следующем октете. Присутствие двоичной единицы в качестве LSB свидетельствует о том, что этот октет поля протокола - последний.

Заметим, что к полю может быть присоединено любое число нулевых октетов, и двоичное значение будет тем же самым (например, вот два двоичных представления числа 3: 00000011 и 00000000 00000011).

При использовании узкополосных каналов желательно экономить пропускную способность, посылая как можно меньше избыточных данных. Опции конфигурации сжатия поля протокола являются компромиссом между требованиями простоты приложения и эффективностью использования пропускной способности. При успешном согласовании для сжатия поля протокола до одного октета может использоваться механизм расширения ISO 3309. Большую часть пакетов можно сжимать, т.к. протоколы данных обычно назначаются со значением поля протокола, меньшим, чем 256.

Сжатые поля протокола не должны передаваться, если эта опция конфигурации не была согласована. После согласования, приложение должно принимать пакеты PPP с однооктетными или двухоктетными полями протокола, и не должно делать различия между ними.

Поле протокола никогда не сжимается при посылке любого пакета LCP. Это правило гарантирует однозначное распознавание пакетов LCP. Когда поле протокола сжато, поле FCS уровня ЗПД рассчитывается не по исходному, а по сжатому кадру.

Формат опции конфигурации сжатия полей протокола показан ниже. Поля передаются слева направо.

Поле "Тип"

7

Поле "Длина"

2 октета.

Сжатие полей адреса и контроля

Эта опция конфигурации обеспечивает метод согласования сжатия полей адреса и контроля (ACFC - Address-and-Control-Field-Compression) ЗПД. По умолчанию все приложения должны передавать кадры с полями адреса и контроля в соответствии с правилами созданием кадров ЗПД.

Так как эти поля обычно имеют постоянные значения для каналов точка-точка (point-to-point), их легко сжимать. Эта опция конфигурации посылается для информирования однорангового объекта о том, что приложение может получить сжатые поля адреса и контроля. Если получен сжатый кадр, а сжатие полей адреса и контроля не было согласовано, то приложение может сбросить кадр без уведомления.

Поля адреса и контроля не должны быть сжаты при посылке любого пакета LCP. Это правило гарантирует однозначное распознавание пакетов LCP. Когда поля адреса и контроля сжаты, поле FCS уровня ЗПД рассчитывается не по исходному, а по сжатому кадру.

Формат опции конфигурации сжатия полей адреса и контроля показан ниже. Поля передаются слева направо.

Поле "Тип"

8

Поле "Длина"

2 октета.

Заключение

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

Отдельное внимание было уделено функциональной структуре данной сети, а именно:

— основным принципам построения;

— технологии IP, ATM, Softswitch;

— основные протоколы сети NGN.

Идеология      построения   NGN    обеспечивает     возможность предоставления абонентам услуг Triple-Play (передача речи, данных и видео) на базе мультисервисных сетей, создаваемых путем модернизации существующих сетей электросвязи. Переход к NGN открывает практически неограниченные возможности по реализации услуг и для корпоративного сектора. В традиционных сетях такие услуги предоставляются локальными операторами, и их подключение нередко требует больших временных или финансовых затрат. В случае использования однородной IP-среды существует единый набор услуг для всех пользователей. Механизм их подключения также заметно упрощается: достаточно выбрать интересующую услугу из списка и послать соответствующий запрос. Уже сегодня популярны новые широкополосные услуги: «видео по требованию», «расширенное телевидение» (ТВ+Интернет), ТВ – коммерция и т. д.

Но следует обратить внимание на две опасности. Прежде всего, построение одной (единой) мультисервисной сети вызывает снижение надежности и живучести инфокоммуникационной системы. Еще одна сложность связана с IP-технологией. Речь идет об информационной безопасности. Данная проблема активно обсуждается специалистами, однако рекомендации, существенные для практической работы, пока не сформулированы.

Литература

1.      Simpson W., "The Point-to-Point Protocol (PPP)", Network Working Group, Request for Сomments 1661, STD: 51, July 1994.

2.      Perkins, D., "Requirements for an Internet Standard Point-to-Point Protocol", RFC 1547, Carnegie Mellon University, December 1993.

3.      Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.

4.      Протоколы сетей ATM http://book.itep.ru/