RFC 2364 PPP Over AAL5

Network Working Group                                                G. Gross
Request for Comments: 2364                                Lucent Technologies
Category: Standards Track                                           M. Kaycee
                                                                     Paradyne
                                                                       A. Lin
                                                              Shasta Networks
                                                                     A. Malis
                                                        Ascend Communications
                                                                  J. Stephens
                                                               Cayman Systems
                                                                    July 1998

PPP Over AAL5

PPP на основе AAL5

PDF

Статус документа

Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит запросом обсуждения и предложений для развития протокола. Состояние стандартизации и статус протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

Авторские права

Copyright (C) The Internet Society (1998). All Rights Reserved.

Аннотация

PPP¹ [1] обеспечивает стандартный способ передачи дейтаграмм по каналам «точка-точка» для множества протоколов.

Этот документ ²описывает использование уровня адаптации AAL5 для кадрирования пакетов с инкапсуляцией PPP.

Применимость

Данная спецификация адресована разработчикам, которые желают использовать возможности, определенные для PPP, такие как протокол управления каналом LCP³, протоколы управления сетевого уровня NCP⁴, проверка подлинности и компрессия. Эти возможности требуют наличия между партнерами соединений «точка-точка» и не предназначены для многоточечных соединений, доступных в ATM и других средах с множественным доступом.

1. Введение

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

Большинство имеющихся реализаций PPP использует ISO 3309 HDLC в качестве основы для кадрирования [3].

При настройке сети ATM на соединения «точка-точка» PPP может использовать механизм кадрирования AAL5.

2. Соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с документом [10].

3. Интерфейс уровня AAL5

Уровень PPP рассматривает нижележащий уровень ATM AAL5 как синхронный битовый канал «точка-точка». В этом контексте канал PPP соответствует виртуальному соединению ATM AAL5. Виртуальное соединение должно быть полнодуплексным соединением «точка-точка» и может быть выделенным (т. е. постоянным) или коммутируемым (по запросу). Кроме того, граница сервисного интерфейса PPP/AAL5 должна удовлетворять приведенным ниже требованиям.

Interface Format – формат интерфейса

Граница уровней PPP/AAL5 представляет сервисный интерфейс с уровнем AAL5 на основе октетов. Субоктетные элементы не предусмотрены и не воспринимаются.

Transmission Rate – скорость передачи

Уровень PPP не вносит каких-либо ограничений для скорости передачи и параметров дескрипторов трафика базового уровня ATM.

Control Signals – сигналы управления

Уровень AAL5 должен обеспечивать сигналы управления для уровня PPP, указывающие организацию и разрыв соединений. Это выполняется с помощью событий Up и Down машины состояний LCP [1] на уровне PPP.

4. Многопротокольная инкапсуляция

Эта спецификация использует принципы, терминологию и структуру кадров, описанные в документе «Multiprotocol Encapsulation over ATM Adaptation Layer 5» [4].

Целью этой спецификации является не документирование того, что уже стандартизовано в [4], а описание способов использования описанных в [4] механизмов для отображения PPP на сеть ATM с уровнем адаптации AAL5. В разделе 1 работы [4] определены два механизма идентификации типа протокола в поле данных PDU⁵ – мультиплексирование виртуальных устройств и инкапсуляция LLC⁶. В первом методе тип протокола в поле данных (payload) неявно согласуется конечными точками для каждого виртуального устройства с использованием процедур обеспечения (provisioning) или уровня управления. При использовании инкапсуляции LLC тип протокола в поле данных явно указывается для PDU с помощью заголовка LLC, за которым следуют данные (payload).

При транспортировке данных PPP с использованием AAL5 предъявляются перечисленные ниже требования.

1. Должны поддерживаться мультиплексируемые по виртуальным устройствам данные PPP, как описано в разделе 5, на основе настройки или взаимного согласования обеих конечных точек. Этот метод называется VC-multiplexed PPP (PPP с мультиплексированием VC).

2. Должны поддерживаться инкапсулированные в LLC данные PPP на соединениях PVC, как описано в разделе 6, на основе настройки или взаимного согласования обеих конечных точек. Этот метод называется LLC encapsulated PPP (PPP с инкапсуляцией LLC).

3. Для организации коммутируемых соединений SVC реализация должна согласовать использование процедуры Q.2931 [9] Annex C, кодирующую информационные элементы B-LLI⁷ в сигналы VC-multiplexed PPP или LLC encapsulated PPP. Детали этой процедуры уровня управления описана в разделе 7.

Если реализация подключается к конечной точке RFC 1973 [6] с использованием блока межсетевого обслуживания Frame Relay/ATM FRF.8 [7], она должна использовать инкапсуляцию LLC для данных PPP. Блоки межсетевого сервиса Frame Relay/ATM FRF.8 освобождены от необходимости поддержки PPP с мультиплексированием VC, что позволяет сохранить совместимость FR/ATM IWU с FRF.8 при межсетевом взаимодействии конечных точек PPP на основе AAL5 с конечными точками RFC 1973.

5. PPP с мультиплексированием VC для PPP на основе AAL5

Формат AAL5 PDU показан на рисунке 1.

+-------------------------------+
|             .                 |
|             .                 |
|        CPCS-PDU Payload       |
|     до (2^16 - 1 октетов)     |
|             .                 |
+-------------------------------+
|      PAD ( 0 - 47 октетов)    |
+-------------------------------+ -------
|       CPCS-UU (1 октет )      |    ^
+-------------------------------+    |
|         CPI (1 октет )        |    |
+-------------------------------+Трейлер CPCS-PDU 
|        Length (2 октета)      |    |
+-------------------------------|    |
|         CRC (4 октета)        |    V
+-------------------------------+ -------

Рисунок 1. Формат AAL5 CPCS-PDU.

Поле подуровня конвергенции CPCS⁸-PDU Payload содержит пользовательские данные размером до 2¹⁶ – 1 октетов.

Поле PAD дополняет CPCS-PDU в ячейке ATM, чтобы 48 октетов последней ячейки, созданной подуровнем SAR, имели трейлер CPCS-PDU в конце ячейки.

Поле CPCS-UU⁹ служит для прозрачной передачи информации CPCS между пользователями. Назначение этого поля не задается в описанной здесь многопротокольной инкапсуляции ATM и поле может принимать любые значения.

Поле CPI¹⁰ выравнивает трейлер CPCS-PDU до 64 битов. Другие возможные применения поля изучаются в рамках ITU-T. При использовании для выравнивания в поле следует устанавливать значение 0x00.

Поле Length указывает размер поля Payload в октетах. Максимальное значение поля Length составляет 65535. Значение Length = 0x00 служит для функции прерывания.

Поле CRC служит для защиты всего CPCS-PDU без самого поля CRC.

Кадру PPP с мультиплексированием VC нужно задавать данные CPCS-PDU, как показано на рисунке 2.

+-------------+-------------+---------+
| Protocol ID | Information | Padding |
|  8/16 битов |             |         |
+-------------+-------------+---------+

Рисунок 2.

Каждое из этих полей определено в документе [1].

6. PPP с инкапсуляцией LLC на основе AAL5

Инкапсуляция LLC для PPP на основе AAL5 является альтернативой мультиплексированию VC.

Кодирование полей AAL5 CPCS-PDU показано на рисунке 3.

1. Заголовок LLC – 2 байта, используемые для указания SAP источника и получателя маршрутизируемого OSI PDU (, значения 0xFE), за которыми следует поле типа кадра UI¹¹ со значением 0x03.

2. Идентификатор протокола сетевого уровня NLPID¹², представляющий PPP (значение 0xCF).

3. Поле идентификатора протокола PPP размером 1 или 2 октета [1].

4. Информационное поле PPP, показанное на рисунке 2.

+-------------------------+ --------
|  Destination SAP (0xFE) |     ^
+-------------------------+     |
|  Source SAP (0xFE)      | Заголовок LLC 
+-------------------------+     |
|  Frame Type = UI (0x03) |     V
+-------------------------+ --------
|  NLPID = PPP (0xCF)     |
+-------------------------+ --------
|   Protocol Identifier   |     ^
|     (8 или 16 битов)    |     |
+-------------------------+ Данные PPP 
|          .              |     |
|          .              |     |
| Информационное поле PPP |     |
|          .              |     |
|          .              |     |
+-------------------------+     |
|        padding          |     V
+-------------------------+ --------
|  PAD ( 0 - 47 октетов)  |
+-------------------------+ --------
|  CPCS-UU (1 октет )     |     ^
+-------------------------+     |
|    CPI (1 октет )       |     |
+-------------------------+Трейлер CPCS-PDU 
|   Length (2 октета)     |     |
+-------------------------|     |
|    CRC (4 октета)       |     V
+-------------------------+ --------

Рисунок 3.

Конечные точки могут быть настроены на передачу чрез соединение с инкапсуляцией LLC не только пакетов PPP. Однако им недопустимо передавать пакеты, относящиеся к любому протоколу, которые имеет активный NCP в рамках сессии PPP. Реализациям следует выполнять планирование пакетов с минимальным влиянием производительности на обязательства по качеству обслуживания, связанные как с инкапсулированными в LLC потоками PPP, так и с потоками, не относящимися к PPP.

7. Сигналы управления по отдельному каналу

При создании коммутируемого соединения AAL5 вызывающая сторона должна запросить в соединении SETUP поддержку PPP с мультиплексированием VC, инкапсуляции LLC или обоих вариантов. При запросе обоих методов вызывающей стороной кодируются два B-LLI IE в Broadband Repeat Indicator IE в соответствии с порядком предпочтения. Реализация вызываемой стороны должна быть способна воспринимать входящие вызовы, которые предлагают инкапсуляцию LLC для PPP в запросе вызывающего. Реализация вызываемой стороны должна отвергать запросы на организацию соединения, которые предлагают неподдерживаемую инкапсуляцию. Реализации, инициирующие соединение с предложением обоих методов должны быть способны согласовать использование инкапсуляции LLC для PPP.

При вызове с мультиплексированием виртуальных устройств для передачи данных PPP поле протокола уровня 3 элемента ITU Q.2931 [9] B-LLI в октете 7 указывает ISO/IEC TR 9577 [5]. Октеты расширения задают для IPI значение PPP (0xCF). По определению первые байты поля данных кадра AAL5 всегда содержат заголовок PPP, за которым следует пакет.

При вызове с инкапсуляцией LLC для передачи данных поле протокола уровня 2 в элементе ITU Q.2931 B-LLI в октете 6 указывает протокол управления канальным уровнем ISO/IEC8802-2. Пример этого приведен в Приложении A к RFC 1755 [8]. По определению первые байты поля данных кадра AAL5 содержат заголовок LLC, за которым следует NLPID и данные PPP.

8. Детектирование незапрошенной смены метода инкапсуляции и восстановление после смены метода

При потере состояния VC метод инкапсуляции PPP может неожиданно меняться в одностороннем порядке. Процедуры детектирования и восстановления определены для следующих переходов:

смена VC-multiplexed PPP на LLC encapsulated PPP;

смена LLC encapsulated PPP на VC-multiplexed PPP.

При использовании PPP с инкапсуляцией LLC начальные 6 октетов пакетов LCP содержат последовательность fe-fe-03-cf-c0-21, составляющую первые 6 октетов кадра AAL5. При использовании PPP с мультиплексированием VC, начальные пакеты LCP содержат последовательность c0-21, составляющую два первых октета кадра AAL5. Когда получен и распознан пакет LCP Configure-Request, канал PPP переходит в фазу Link Establishment.

После перехода PPP в фазу Network-layer Protocol и согласования конкретного NCP для протокола PPP получения кадра с другой, но эквивалентной с соответствии с определением [4], инкапсуляцией данных канал PPP должен:

для SVC незамедлительно сбросить соединение с кодом причины 111 (protocol error, unspecified);

для PVC отключить активные NCP; следует также генерировать сообщение об ошибке, перейти в состояние Termination и отбрасывать все полученные пакеты без уведомления отправителя.

Эти правила предотвращают «черные дыры», которые возникают при потере партнером состояния. Реализация, которая требует настройки канала PPP и других согласуемых функций PPP (например, аутентификации), может перейти в состояние Termination при отказе конфигурации.

9. Конфигурационные опции LCP

Конфигурационная опция LCP Magic Number рекомендуется, а опция PFC¹³ не рекомендуется. Реализации недопустимо запрашивать какие-либо из перечисленных ниже опций и она должна отвергать эта опции:

Field Check Sequence (FCS) Alternatives;

Address-and-Control-Field-Compression (ACFC);

Asynchronous-Control-Character-Map (ACCM).

В опции MRU¹⁴ недопустимо согласовывать значение, превышающее максимальный размер CPCS-SDU, заданный для соответствующего направления контрактом на трафик виртуального соединения.

Соединение между партнерами PPP может проходить через мосты множества секций физического уровня. Для каждой такой секции AAL5 опции кадрирования LCP должны активно согласовываться «мостовыми преобразователями» (bridging convertor), независимо от опций кадрирования LCP, используемых другими секциями физического уровня.

Примечание для разработчиков.

Когда ATM AAL5 PVC находится в состоянии Stopped (остановлено), реализации рекомендуется ждать сообщений Configure-Request (см. примечание для разработчиков в параграфе 4.2, состояние Stopped, документа [1]).

10. Вопросы безопасности

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

Когда в публичной сети ATM поддерживаются коммутируемые соединения SVC¹⁶, модель протокола становится аналогичной обычным модемным соединениям в телефонной сети общего пользования (PTSN¹⁷). Используются те же протоколы проверки подлинности PAP/CHAP, которые получили широкое распространение для доступа в Internet по телефонным линиям. В результате защита соединений PPP на основе AAL5 выполняется на основе методов, применяемых в существующей инфраструктуре Internet.

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

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

11. Благодарности

Этот документ основан на результатах работы группы Packet Mode под эгидой ADSL Forum. Источником вдохновения послужила работа «PPP in Frame Relay», RFC 1973, подготовленная William Simpson. Отдельная благодарность Phil Rakity из Flowpoint, Tim Kwok из Microsoft и David Allan из Nortel за их конструктивные замечания и рецензии.

12. Литература

[1] Simpson, W., Editor, “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, July 1994.

[2] The ATM Forum, “Frame based User-to-Network Interface (FUNI) Specification v2”, af-saa-0088.000, May 1997.

[3] Simpson, W., Editor, “PPP in HDLC-like Framing”, STD 51, RFC 1662, July 1994.

[4] Heinanen, J., “Multiprotocol Interconnect over AAL5”, RFC 1483, July 1993.

[5] ISO/IEC DTR 9577.2, “Information technology – Telecommunications and Information exchange between systems – Protocol Identification in the network layer”, 1995-08-16.

[6] Simpson, W., “PPP in Frame Relay”, RFC 1973, June 1996.

[7] The Frame Relay Forum, “Frame Relay/ATM PVC Service Interworking Implementation Agreement”, FRF.8, April 1995.

[8] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and A. Malis, “ATM Signaling Support for IP over ATM”, RFC 1755, February 1995.

[9] International Telecommunication Union, “Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control”, ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 2/95)

[10] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

Адрес руководителя

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

Karl Fox

Ascend Communications

3518 Riverside Drive, Suite 101

Columbus, Ohio 43221

EMail: karl@ascend.com

Адреса авторов

Связанные с документом вопросы можно адресовать авторам, перечисленным ниже.

George Gross

Lucent Technologies, Inc

184 Liberty Corner Road

Warren, NJ 07059

Phone: +1.908.580.4589

EMail: gmgross@lucent.com

Manu Kaycee

Paradyne Corporation

21 Bear Meadow Road

Londonderry, NH 03053-2168

Phone: +1.603.434.6088

EMail: mjk@nj.paradyne.com

Arthur Lin

Shasta Networks Inc.

249 Humboldt Court

Sunnyvale, CA 94089-1300

Phone: +1.408.747.5051

EMail: alin@shastanets.com

Andrew Malis

Ascend Communications, Inc.

1 Robbins Road

Westford, MA 01886

Phone: +1.978.952.7414

EMail: malis@ascend.com

John Stephens

Cayman Systems, Inc.

100 Maple Street

Stoneham, MA 02180

Phone: +1.617.279.1101

EMail: john@cayman.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.