AAA

RFC 4638 — Согласование для протокола PPPoE значений MTU/MRU более 1492

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

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

Замечание IESG

На момент создания этого документа не была стандарта IEEE, поддерживающего использование "jumbo-кадров" (MTU более 1500). Хотя в этом документе описан рекомендуемый механизм обнаружения проблем, связанных с использованием таких кадров, интероперабельность и надежность нестандартных расширений не может быть гарантирована. Разработчикам и пользователям описанного здесь протокола следует с осторожностью подходить к его применению.

Тезисы

Протокол PPPoE (Point-to-Point Protocol over Ethernet), описанный в RFC 2516, диктует ограничение на максимальное значение согласованного размера максимального принимаемого блока данных (MRU, Maximum Receive Unit) — 1492. В этом документе предложено решение, позволяющее смягчить данное ограничение и позволить согласование значений MRU более 1492 для снижения уровня фрагментации в широкополосных сетях нового поколения.

Оглавление

1. Введение

Широкополосные сети переходят от инициируемых ПК сессий PPPoE [1] и инфраструктуры Ethernet/ATM (см. рисунок 1) к более интеллектуальным системам PPPoE со шлюзами RG и инфраструктурой Gigabit Ethernet/ATM (рис. 2 и 3), требуя при этом повышения максимального размера передаваемых и принимаемых блоков информации PPPoE для снижения уровня фрагментации пакетов в сети.

  <------------------ PPPoE session ------------------>

                                  +-----+           +-----+
+--+              +---+           |     |           |     |
|PC|--------------|CPE|-----------|DSLAM|-----------| BRAS|
+--+  <Ethernet>  +---+   <ATM>   |     |   <ATM>   |     |
                                  +-----+           +-----+

Рисунок 1: Традиционная структура широкополосной сети PPPoE.

В схеме, показанной на рисунке 1, фрагментация обычно не вызывает проблем, поскольку абонентские сеансы PPPoE организуются между ПК и BRAS. Следовательно, согласование для PPP значения MRU в 1492 октета приемлемо, поскольку оно обеспечивает возможность включения кадра PPPoE с максимальным размером в стандартный блок Ethernet MTU (1500 октетов).

<----- IPoE -----> <--------- PPPoE session --------->

                                  +-----+            +-----+
+--+              +---+           |     |            |     |
|PC|--------------| RG|-----------|DSLAM|------------| BRAS|
+--+  <Ethernet>  +---+   <ATM>   |     |   <GigE>   |     |
                                  +-----+            +-----+

Рисунок 2: Структура сети PPPoE нового поколения.

В сети, показанной на рисунке 2, фрагментация становится основной проблемой, поскольку абонентская сессия объединяет в себе IpoE и PPPoE. Протокол IPoE обычно использует значение MTU в 1500 октетов. Однако, когда шлюз RG и концентратор BRAS являются конечными точками сессий PPPoE и, следовательно, не могут согласовать между собой значения MTU/MRU более 1492 октетов, в результате в сети существенно повышается уровень фрагментации пакетов.

 <----- IPoE -----> <---- PPPoA ----> <- PPPoE session ->

                                   +-----+            +-----+
+--+              +---+            |     |            |     |
|PC|--------------| RG|------------|DSLAM|------------| BRAS|
+--+  <Ethernet>  +---+    <ATM>   |     |   <GigE>   |     |
                                   +-----+            +-----+


  <-------------- PPPoA -------------> <- PPPoE session ->

                                   +-----+            +-----+
+--+              +---+            |     |            |     |
|PC|--------------|CPE|------------|DSLAM|------------| BRAS|
+--+    <ATM>     +---+    <ATM>   |     |   <GigE>   |     |
                                   +-----+            +-----+

Рисунок 3: Широкополосная сеть с преобразованием PPPoA-PPPoE

В показанной на рисунке 3 схеме сети, которая исследовалась в DSL-Forum в контексте перехода к Ethernet для широкополосных объединенных сетей, фрагментация не является единственной проблемой, когда существует различие между MRU для сеансов PPPoA (Point-to-Point Protocol over AAL5) и PPPoE.

Пользовательская сессия представляет собой сеанс PPP, работающий через комбинацию PPPoA и PPPoE. Хост PPP/PPPoA обычно согласует значение 1500 октетов для MRU. Широко распространенные хосты PPP/PPPoA в оборудовании CPE (Customer Premises Equipment) не поддерживают MRU в 1492 октета, что создает проблему для BRAS (сервер PPPoE) при строгом выполнении требований RFC 2516 [1]. Если хосты PPP/PPPoA способны согласовать MRU=1492, мы возвращаемся к проблеме фрагментации.

2. Терминология

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

3. Предлагаемое решение

Процедура, описанная в этом документе, не соответствует в точности требованиям стандартов IEEE для размера пакетов Ethernet, но она основана широко распространенных кадрах с форматом пакетов Ethernet, хотя их размер превышает максимально допустимое значение, заданное в [4].

Поскольку широкополосные сети нового поколения строятся на базе систем Ethernet, поддерживающих кадры baby-giants и jumbo с размером поля данных, превышающим обычное значение Ethernet MTU в 1500 октетов, устройства BRAS, действующие как серверы PPPoE, должны поддерживать для PPPoE MRU согласование значений более 1492 октетов, чтобы ограничить уровень фрагментации пакетов в сети, как было сказано в главе 1.

По умолчанию опция MRU должна соответствовать требованиям RFC 1661 [2], но недопустимо согласовывать значения более 1492 для обеспечения совместимости с сегментами сетей Ethernet, в которых размер кадра ограничен 1500 октетами. Заголовок PPPoE занимает 6 октетов, а идентификатор PPP Protocol ID — 2 octets, что в результате и делает недопустимым для PPP MRU использование значений более 1492.

Необязательный тег PPPoE "PPP-Max-Payload" позволяет клиенту PPPoE изменить принятое по умолчанию поведение, задавая для информационного поля PPP максимальное значение, поддерживаемое в обоих направлениях. Когда сервер PPPoE получает такой тег, он может разрешить согласование значения MRU > 1492 и использовать значения MTU > 1492, в зависимости от заданных локальной конфигурацией параметров и в соответствии с правилами, установленными RFC 1661 [2], а также учитывая максимальный размер информационного поля, заданный клиентом PPPoE.

4. Этап PPPoE Discovery

Если клиент PPPoE желает использовать значение MTU/MRU более 1492 октетов, он должен включить тег PPP-Max-Payload в пакеты PADI и PADR. Если сервер PPPoE может поддерживать MTU/MRU более 1492 октетов, он должен скопировать полученный от клиента тег PPP-Max-Payload в передаваемые клиенту пакеты PADO и PADS.

Описание тега

5. Вопросы LCP

5.1. Согласование MRU

Поскольку для Ethernet (без кадров jumbo) максимальный размер данных ограничен 1500 октетами, заголовок PPPoE занимает 6 октетов, а поле PPP Protocol ID — 2 октета, для опции MRU (Maximum-Receive-Unit) недопустимо согласовывать значение более 1492 октетов, если клиент и сервер PPPoE не указали свою возможность использования больших значений MRU на этапе PPPoE Discovery.

Начальное согласование MRU для сервера PPP/PPPoE должно следовать приведенной ниже процедуре:

If PPPoE {
    PPP_MRU_Max = 1492
    If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492)
        Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)
}
нормальная процедура PPP_MRU_Negotiation (PPP_MRU_Max)

Если присутствует тег PPP-Max-Payload со значением более 1492, это значение должно рассматриваться наряду с установками MTU для интерфейсов сервера при нормальном согласовании в соответствии RFC 1661 [2] используемого протоколом значения MRU.

Если тег PPP-Max-Payload не задан или указывает значение меньше 1492, существующее для MRU ограничение 1492 должно сохранять свою применимость в целях обеспечения совместимости с более ранними версиями.

Таким образом, в результате имеет место следующее поведение:

  1. При получении тега PPP-Max-Payload

    • значение этого тега показывает значение MRU, допущенное или предложенное при согласовании MRU
    • если значение MRU не согласовано, RFC 1661 [2] будет задавать принятое по умолчанию значение MRU = 1500. Это говорит о том, что тег PPP-Max-Payload может указывать значение более 1500, но в этом случае RFC 1661 [2] установит принятое по умолчанию значение 1500, а заданное тегом PPP-Max-Payload большее значение может быть использовано только в тех случаях, когда согласовано достаточно большое значение MRU (вплоть до максимального размера поля данных).
  2. Если тег PPP-Max-Payload не получен ни одной из сторон, используется правило, заданное в RFC 2516 [1].

5.2. Тестирование MRU и поиск неполадок

Если для MRU согласовано значение более 1492 октетов, передающей стороне следует иметь опцию для передачи одного или более пакета Echo-Request размером MRU в начале сеанса. Это позволит убедиться в том, что принимающая сторона, все промежуточные сегменты Ethernet и оборудование могут работать с пакетами такого размера.

Если в ответ не было получено откликов Echo-Replies, передающая сторона может повторить проверку с помощью пакетов Echo-Request размером 1492 октета. Если на эти пакеты будут получены отклики, передающая сторона должна отправлять в этой сессии пакеты размером не более 1492 октетов.

Такую проверку следует включать по умолчанию. Ее следует делать настраиваемой и можно отключать в сетях, где есть основания (предварительный опыт) считать такую проверку ненужной.

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

Этот документ не создает новых проблем, связанных с безопасностью. Вопросы безопасности, относящиеся к исходному протоколу PPPoE [1], сохраняют свою актуальность.

7. Согласование с IANA

Этот документ определяет новое значение в пространстве, для которого в настоящее время не используется реестра IANA. Ведется работа по созданию такого реестра [5] и подготавливаемый документ уже содержит выделенное здесь значение. От IANA не требуется никаких действий в связи с настоящим документом.

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

Авторы выражают свою признательность Prakash Jayaraman, Amit Cohen, Jim Ellis, David Thorne, John Reid, Oliver Thorp, Wojciech Dec, Jim Wilks, Mark Townsley, Bart Salaets, Tom Mistretta, Paul Howard, Dave Bernard и Darren Nobel за их вклад и комментарии к документу.

9. Нормативные документы

  1. Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
  2. Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  3. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  4. Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2005, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications — Draft amendment to — Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Media Access Control Parameters, Physical Layers and Management Parameters", December 2005.

10. Дополнительная литература

  1. Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE), Work in Progress, June 2006.

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

Peter Arberg
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
EMail: moc.kcabder@grebrap

Diamantis Kourkouzelis
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
EMail: moc.kcabder@kdnomaid

Mike Duckett
BellSouth Telecommunications, Inc.
575 Morosgo Drive
Atlanta, GA 30324
EMail: moc.htuoslleb@ttekcud.ekim

Tom Anschutz
BellSouth Science and Technology
725 W. Peachtree St.
Atlanta, GA 30308
EMail: moc.htuoslleb@ztuhcsna.mot

Jerome Moisand
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
EMail: ten.repinuj@dnasiomj

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

Николай Малых, moc.milib@hkylamn