| RFC 1717 RFC 1990 Поддержка
мультиканального режима Multilink основана на опции согласования
параметров PCP, позволяющей станции сообщить станции-партнеру о
возможности объединения нескольких физических каналов передачи данных в
один логический канал. Одного "пакета" физических каналов достаточно
практически для любых условий связи между парой станций.
Согласование параметров выполняется на начальной фазе согласования
опций LCP. Система показывает своему партнеру того же уровня (peer)
намерение использовать мультиканальный режим путем передачи
мультиканальной опции на начальной фазе согласования параметров LCP.
Согласование параметров показывает следующие возможности: Система, предлагающая мультиканальный режим, может объединять несколько физических каналов в одно логическое соединение. Система
способна принимать фрагментированные PDU вышележащих уровней с
использованием мультиканального заголовка и собирать фрагменты в
исходный модуль данных PDU. Система
может принимать PDU размером N октетов, где N задается как часть опций
согласования даже в тех случаях, когда N превышает значение MRU
(максимальный размер принимаемого пакета) для одного физического канала.
При использовании протокола Multilink PPP пакеты сначала
инкапсулируются (но не кадрируются) в соответствии с обычными
процедурами PPP - большие пакеты разбиваются на фрагменты меньших
размеров, приемлемых для физических каналов. Перед каждой секцией
пакета вставляется новый PPP заголовок, содержащий идентификатор
протокола Multilink PPP и заголовок Multilink.. Таким образом, первый
фрагмент мультиканального пакета PPP будет содержать два заголовка -
заголовок фрагмента и заголовок пакета. Фрагменты
Multilink PPP инкапсулируются с использованием идентификатора протокола
0x00 - 0x3d. Вслед за идентификатором протокола размещается
четырехбайтовый заголовок, содержащий порядковый номер, и 2
однобайтовых поля, показывающие первый и последний фрагмент пакета.
После согласования дополнительных опций PPP LCP четырехбайтовый
заголовок может быть заменен двухбайтовым заголовком, после которого
размещаются 12 последовательных нулей. Поля Адрес/Управление и
Идентификатор протокола сохраняют свое назначение. На рисунке показан формат пакетов с длинным порядковым номером фрагмента. | Заголовок PPP | Адрес 0xff | Управление 0x03 | | PID (H) 0x00 | PID (L) 0x3d | | Заголовок MP | B | E | O | O | O | O | O | O | Порядковый номер | | Порядковый номер (L) | |
| Фрагмент данных
.
. , | | PPP FCS | FCS | Фрагмент Multilink PPP с длинным порядковым номером На следующем рисунке показан формат фрагмента с коротким порядковым номером.
| Заголовок PPP | Адрес 0xff | Управление 0x03 | | PID (H) 0x00 | PID (L) 0x3d | | Заголовок MP | B | E | O | O | Порядковый номер | |
| Фрагмент данных
.
. , | | PPP FCS | FCS | Фрагмент Multilink PPP с коротким порядковым номером PID Идентификатор протокола. B Флаг
начального (первого) фрагмента. Нулевое значение этого поля указывает,
что фрагмент не является первым фрагментом пакета PPP, а 1 указывает
первый фрагмент. Таким образом, для последовательности фрагментов этот
бит устанавливается только в заголовке первого фрагмента. E Флаг
конечного (последнего) фрагмента. Нулевое значение этого поля
указывает, что фрагмент не является последним фрагментом пакета PPP, а
1 указывает последний фрагмент. Это поле имеет нулевое значение для
всех фрагментов пакета PPP, кроме последнего. Порядковый номер 24-х
или 12-битовый номер фрагмента. Фрагменты нумеруются по порядку с
увеличением номера на 1. По умолчанию используются 24-битовые (длинные)
номера, но при согласовании опций конфигурации LCP можно договориться
об использовании 12-битовых (коротких) номеров. O Зарезервированные
поля между флагом последнего фрагмента и порядковым номером. Эти поля в
настоящее время не используются и должны иметь нулевые значения. В
пакетах с длинным порядковым номером используется 6 полей O, в пакетах
с коротким номером - 2. FCS Контрольная
сумма. Значение контрольной суммы наследуется от обычного механизма
кадрирования для канала, по которому передается пакет.
| 
