Network Working Group Request for Comments: 4638 Category: Informational
P. Arberg
D. Kourkouzelis
Redback Networks
M. Duckett
T. Anschutz
BellSouth
J. Moisand
Juniper Networks
September 2006
Согласование для протокола PPPoE значений MTU/MRU более 1492
Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU)
Greater Than 1492 in the
Point-to-Point Protocol over Ethernet (PPPoE)
Статус документа
В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2006).
Замечание IESG
На момент создания этого документа не была стандарта IEEE, поддерживающего использование "jumbo-кадров" (MTU более 1500). Хотя в этом документе описан рекомендуемый механизм обнаружения проблем, связанных с использованием таких кадров, интероперабельность и надежность нестандартных расширений не может быть гарантирована. Разработчикам и пользователям описанного здесь протокола следует с осторожностью подходить к его применению.
Тезисы
Протокол PPPoE (Point-to-Point Protocol over Ethernet), описанный в RFC 2516, диктует ограничение на максимальное значение согласованного размера максимального принимаемого блока данных (MRU1) - 1492. В этом документе предложено решение, позволяющее смягчить данное ограничение и позволить согласование значений MRU более 1492 для снижения уровня фрагментации в широкополосных сетях нового поколения.
Оглавление
1. Введение .............................
2. Терминология ...................
3. Предлагаемое решение .....
4. Этап PPPoE Discovery .......
5. Вопросы LCP .....................
5.1. Согласование MRU..
5.2. MRU Test and Troubleshooting.........................................................................................................................................................4
6. Вопросы безопасности..................................................................................................................................................................................4
7. Согласование с IANA.....................................................................................................................................................................................4
8. Благодарности.............................................................................................................................................................................................4..
9. Нормативные документы...........................................................................................................................................................................4
10. Дополнительная литература.......................................................................................................................................................................5
1Maximum Receive Unit
rfc.com.ru
rfc.com.ru
Перевод RFC 4638
1. Введение
<----------------- сессия РРРоЕ ------------------->
Широкополосные сети переходят от инициируемых ПК сессий PPPoE [1] и инфраструктуры Ethernet/ATM (см. рисунок 1) к более интеллектуальным системам PPPoE со шлюзами RG2 и инфраструктурой Gigabit Ethernet/ATM (рис. 2 и 3), требуя при этом повышения            максимального            размера
передаваемых и принимаемых блоков информации PPPoE для снижения уровня фрагментации пакетов в сети.
+—+ |РС|-
+—+
<Ethernet>
+-----+
+----+
+---+
1 1
1 1
| OJ^JL |
+---+
<ATM>
1 1
+-----+
<ATM>
1 1
+----+
Рисунок 1: Традиционная структура широкополосной сети PPPoE.
<-----IPoE-----> <--------сессия РРРоЕ--------->
+--+                              +--+
|PC| -------------- |RG|-+--+ <Ethernet> +--+
<ATM>
+-----+
I I
- IDSLAMI-
I I
+-----+
<GigE>
В схеме, показанной на рисунке 1, фрагментация
обычно не вызывает проблем, поскольку +----+ абонентские сеансы PPPoE организуются между | | ПК и BRAS. Следовательно, согласование для |BRAS| PPP значения MRU в 1492 октета приемлемо, | | поскольку оно обеспечивает возможность +----+ включения кадра PPPoE с максимальным
размером в стандартный блок Ethernet MTU
(1500 октетов).
Рисунок 2: Структура сети PPPoE нового поколения.
В сети, показанной на рисунке 2, фрагментация          становится          основной
проблемой, поскольку абонентская сессия объединяет в себе IpoE и PPPoE. Протокол IPoE обычно использует значение MTU в 1500 октетов. Однако, когда шлюз RG и концентратор BRAS3 являются конечными точками сессий PPPoE и, следовательно, не могут согласовать между собой значения MTU/MRU более 1492 октетов, в результате в сети существенно повышается уровень фрагментации пакетов.
<-----IPoE-----> <----РРРоА----> <- сессия РРРоЕ ->
|РС|-
<Ethernet>
+-----+
+----+
+—+
1 1
1 1
|КЬ|
+—+
<ATM>
1 1
+-----+
<GigE>
1 1
+----+
<-------------РРРоА------------> <- сессия РРРоЕ ->
|РС|-
<ATM>
+---+
-|СРЕ|-
+---+
<ATM>
+-----+
I I
-IDSLAMI-
I I
+-----+
<GigE>
+----+
I I
-|BRAS|
I I
+----+
В показанной на рисунке 3 схеме сети, которая исследовалась в DSL-Forum в контексте перехода к Ethernet для широкополосных объединенных сетей4, фрагментация не
является единственной проблемой, когда
Рисунок 3: Широкополосная сеть с преобразованием PPPoA-PPPoE
существует различие между 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].
ATM - асинхронный режим передачи (Asynchronous Transfer Mode)
PPP - протокола связи “точка-точка” (Point-to-Point Protocol)
PPPoA – протокол PPP через AAL5 (PPP over AAL5)
PPPoE – протокол PPP через Ethernet (PPP over Ethernet)
MTU - максимальный размер передаваемого блока (Maximum Transmit Unit)
MRU - максимальный размер принимаемого блока (Maximum Receive Unit)
PC - персональный компьютер (Personal Computer)
CPE - оборудование, размещенное у абонента (Customer Premises Equipment)
RG - шлюз, расположенный в жилом районе (Residential Gateway)
BRAS - широкополосный сервер удаленного доступа (Broadband Remote Access Server)
DSLAM – мультиплексор цифровых абонентских линий доступа (Digital Subscriber Line Access Multiplexer)
PPPoE client – клиентский ПК, RG или CPE, инициирующие сеанс PPPoE
PPPoE server – сервер BRAS, завершающий инициированную клиентом сессию PPPoE
PADI - пакет обнаружения сервера (PPPoE Active Discovery Initiation)
2Residential Gateway – шлюз в жилом районе.
3Broadband Remote Access Server – широкополосный концентратор удаленного доступа.
4В оригинале aggregation networks.
rfc.com.ru
rfc.com.ru
2
Перевод RFC 4638
PADO - пакет с предложением услуг от сервера (PPPoE Active Discovery Offer)
PADR - запрос на обслуживание клиента (PPPoE Active Discovery Request)
PADS - подтверждение сеанса PPPoE (PPPoE Active Discovery Session-confirmation)
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.
Tag-name: PPP-Max-Payload
Tag-value: 0x0120
Tag-length: 2 октета
Tag-value: бинарное значение (максимальный размер поля данных PPP в октетах)
Описание тега
Этот тег показывает, что клиент и сервер способны поддерживать указанное в теге максимальное значение размера поля данных PPP более 1492 октетов для обоих направлений обмена данными. Отметим, что это значение определяет размер данных PPP и, следовательно, его можно напрямую сопоставлять со значением, используемым при согласовании PPP MRU.
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
a)   значение этого тега показывает значение MRU, допущенное или предложенное при согласовании MRU
b)   если значение 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].
rfc.com.ru                                                                          3                                                                        rfc.com.ru
Перевод RFC 4638
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 25165, February 1999.
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 16614, July 1994.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 21194, 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. Дополнительная литература
[5] 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: parberg@redback.com
Diamantis Kourkouzelis
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
EMail: diamondk@redback.com
Mike Duckett
BellSouth Telecommunications, Inc.
575 Morosgo Drive
Atlanta, GA 30324
EMail: mike.duckett@bellsouth.com
Tom Anschutz
5Перевод этого документа на русский язык имеется на сайте http://rfc.com.ru. Прим. перев.
rfc.com.ru                                                                                     4                                                            rfc.com.ru
Перевод RFC 4638                                                                                         
BellSouth Science and Technology
725 W. Peachtree St.
Atlanta, GA 30308
EMail: tom.anschutz@bellsouth.com
Jerome Moisand
Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 EMail: jmoisand@juniper.net
Перевод на русский язык
Николай Малых nmalykh@bilim.com
Полное заявление авторских прав
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).
rfc.com.ru
5
rfc.com.ru