Кратко
- Фрагменты на нескольких линиях использовали последовательность всего bundle. B и E отмечали начало и конец пакета; номер рос на каждом фрагменте и не сбрасывался при новом пакете или подключении участника.
- Общий договор не требовал равных частей или одного планировщика. Небольшой пакет мог остаться целым, а MRRU ограничивал максимальный размер, который получатель обещал собрать.
- FCS каждой линии защищал её фрагмент, но не собранный пакет. Endpoint Discriminator помогал назначать bundle без аутентификации; BAP/BACP и многоклассовое расширение отдельно решали управление полосой и задержкой.
Дополнительная линия не становилась отдельной сетью
Если два PPP-канала представить как независимые интерфейсы, вместе с пропускной способностью удваиваются адреса, переговоры сетевых протоколов и операционное состояние. Если же просто разложить байты одного пакета по линиям, различия скорости и задержки нарушат порядок, а получатель не поймёт, какая часть запаздывает.
Multilink ввёл промежуточный объект — bundle. У каждого участника сохранились framing, LCP и аутентификация. Протоколы сетевого уровня обычно согласовывались один раз для совокупности. Линия могла войти или выйти, не уничтожая автоматически разговор над ней.
RFC 1717 представил механизм в 1994 году, особенно имея в виду несколько B-каналов ISDN. RFC 1990 заменил его в 1996-м и уточнил правила. Слово «агрегация» описывает результат, но не главное решение: какой минимум состояния должен оставаться общим при изменении физического состава.
Делился логический пакет, а не готовый кадр линии
Отправитель сначала добавлял к сетевому пакету обычное поле PPP Protocol. Address, Control, Flags и FCS конкретного участника ещё не относились к этому объекту. Именно такой инкапсулированный пакет допускал фрагментацию.
Каждая часть передавалась как PPP-протокол 0x003d с заголовком MP. Поэтому первый фрагмент начинался с исходного Protocol. Бит B обозначал начало, E — конец. Оба могли быть единицей, если один фрагмент содержал пакет целиком.
Следовательно, Multilink не требовал резать всё. Маленький пакет мог пройти одной частью, а крупный не обязан был делиться поровну. Планировщик мог учитывать скорость линий или выбирать другую локальную стратегию. Получателю не нужно было знать её причины — достаточно было общей грамматики порядка и границ.
Стандарт определил необходимое для совместимости и оставил пространство для работающего кода. Один алгоритм производительности не стал частью wire-контракта.
Счётчик принадлежал всему bundle
Обычный заголовок нёс 24-битный sequence number. Стороны могли согласовать короткий вариант из 12 бит, но один формат действовал на всём bundle. Каждый фрагмент получал следующее число.
Счётчик не начинался заново на каждом исходном пакете. Подключение второй линии к существующему bundle тоже его не сбрасывало. С нуля начинался действительно новый bundle. Иначе малые номера нового участника могли бы напоминать старые фрагменты, задержавшиеся на другой линии.
Получатель вёл одну структуру reassembly для всего bundle. Разные скорости и задержки естественно меняли порядок прибытия. Получатель отслеживал прогресс на каждом активном участнике и вычислял минимальную точку, которую прошли все. Если более старого номера всё ещё не было, его уже нельзя было объяснить только задержкой на медленной линии; незавершённый пакет можно было отбросить и продолжить сборку.
Буфер не отменял неопределённость. Требуемый объём зависел от скоростей, задержек и размера фрагментов. RFC 1990 отмечал, что никакой буфер не гарантирует обнаружение, если peer удерживает пакет. Последовательность делает реконструкцию ограниченной задачей, но не даёт надёжность.
Хорошие FCS отдельных частей не создавали отсутствующий пакет
Каждый участник помещал MP-фрагмент в обычный PPP-кадр и вычислял свой FCS. Правильный FCS свидетельствовал о проверке данной части на данной линии. После объединения MP не добавлял новый FCS для целого пакета.
Десять частей могут пройти проверку, а одиннадцатая — не прийти. Пакет всё равно не готов. Поэтому чистые FCS-счётчики и полная доставка bundle — разные утверждения.
MP не предписывал единый детектор отказа линии. LQM или LCP Echo могли дать сигнал, но оставались отдельными механизмами. Для надёжной доставки на участнике отдельно согласовывался PPP Reliable Transmission. MP упорядочивал и собирал; он не повторял передачу и не подтверждал результат приложения.
Диагностика должна разделять состояние участника, ошибки framing/FCS, последний номер на каждой линии, минимум bundle, пробелы, сбросы неполных пакетов, число готовых пакетов и эффект наверху. Единый зелёный статус уничтожает место возникновения ошибки.
MRRU описывал обещание сборки
Maximum Reconstructed Receive Unit задавал крупнейшее собранное информационное поле, которое принимал получатель bundle. Это не MRU физического участника. Линия должна была вместить только свой фрагмент, а логический пакет мог быть больше в пределах MRRU.
Опция LCP MRRU имела тип 17 и явно показывала способность принимать Multilink или присоединять линию к bundle. RFC 1990 потребовал поддержку хотя бы 1500 октетов и убрал неоднозначный default раннего документа. Short Sequence Header Format получил тип 18.
Endpoint Discriminator типа 19 помогал определить, что несколько линий ведут к одному peer и должны входить в один bundle. Сам по себе он не объявлял MP и не доказывал личность. Некоторые классы назначались локально без глобальной уникальности. Magic-Number Block был лишь вероятно уникален и не рекомендовался как ключ базы или аутентификации при наличии настоящей проверки.
Discriminator можно подделать. Безопасное присоединение требовало PPP-аутентификации. Значение для сопоставления не являлось полномочием.
Решение о дополнительном звонке осталось отдельным
Базовый MP разрешал менять участников, но не решал, когда открывать ещё один звонок и какая сторона управляет полосой. RFC 2125 передал это BACP и BAP. BACP выбирал контролирующий peer, а BAP запрашивал добавление или удаление линии и сообщал состояние звонка.
Успешный звонок доказывал только эту операцию. Он не доказывал нужную конфигурацию участника, передачу MP-фрагментов, рост throughput или доставку транзакции.
Задержка также получила отдельное расширение. RFC 2686 показал, что 1500 байт при 28,8 кбит/с занимают линию примерно на 400 мс и могут приблизить разговорный round trip к секунде. Несколько классов позволили вставлять приоритетные фрагменты между остальными. Базовая последовательность решала сборку, но не всю политику времени.
Bundle был минимальным соглашением
Общими стали способность MP, MRRU, один формат заголовка, границы B/E и пространство последовательности. Размер частей, выбор линии, обнаружение отказа, политика звонка и приоритет оставались локальными или дополнительными.
Bundle не стирал физические линии и не превращался в центральную власть. Он содержал лишь достаточно общего смысла, чтобы разные реализации собрали один пакет при разных решениях планировщика.
0x003d доказывает MP-представление в точке наблюдения. B/E и номер описывают заявленное место фрагмента, MRRU — согласованный предел, discriminator — подсказку сопоставления. Доставка, идентичность, выигрыш полосы и современное развёртывание требуют captures, счётчиков участников, завершённых reassembly и результата верхнего уровня.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
