RFC: 4638
Оригинал: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the
Категория: Информационный
Дата публикации:
Авторы: , , , ,
Перевод: Николай Малых

RFC 4638, Страница 2 из 8

  <------------------ 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, мы возвращаемся к проблеме фрагментации.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.