Тема
Многоадресная маршрутизация
В фасете «Тема» значение «Многоадресная маршрутизация» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
IETF
QUIC хочет multicast. IETF ещё не сказала «да».
На ноябрьской BoF обсудят, можно ли передавать общие данные через Source-Specific Multicast, сохранив отдельное соединение QUIC с каждым получателем. Цель встречи — собрать требования; она не создаёт рабочую группу и не выбирает протокол.
IETF
Черновик RPL экономит чужие батареи с двумя уже занятыми номерами
Узел спрашивает соседей, куда вести маршрут. Соседи отвечают и оплачивают ответ временем в эфире и зарядом. Рабочая группа ROLL при IETF хочет сократить этот счёт. Но два кода, которые проект просит для новых опций, уже выданы IANA другим командам RPL. Сначала придётся навести…
История
Отчёт IGMP подтверждал присутствие, но не число участников
В 1989 году стандарт сделал членство в multicast видимым соседним маршрутизаторам экономным сигналом: один отчёт мог представлять локальную группу, а молчание после ухода истекало лишь по таймеру.
История
Mac мог подключиться, а ретранслятор должен был обслужить всех: CU-SeeMe, 1993–1995
CU-SeeMe позволила передавать живое изображение в интернет с обычного Macintosh. Два участника могли связаться напрямую. Третий менял устройство системы: нужен был компьютер Unix, который принимал, копировал и распределял потоки всех участников. Лёгкий интерфейс на рабочем столе…
Лидеры
Ellen Zegura и ядро многоадресной маршрутизации, которое можно было перенести
Если участники группы многоадресной рассылки перемещаются по сети, выбранный ранее общий маршрутизатор-ядро может оказаться в неудачном месте. В 1996 году Ellen Zegura и Michael J. Donahoo рассмотрели возможность переноса такого ядра как задачу динамической маршрутизации…
NANOG
В CERN не потеряли ни одного пакета, но многие вопросы остались неуслышанными: NANOG 1 и MBONE, 1994 год
Перед первой встречей NANOG в Анн-Арборе организаторы в мае 1994 года сообщили о планах транслировать её через MBONE. Июньский архив рассылки показывает не единый успех и не единый сбой, а разные наблюдения: один участник не нашёл сеанс, другой попросил направить камеру на экран…
История
Групповой адрес называл точку встречи, но не доказывал, что она существует: RFC 3956
RFC 3956 позволила вычислять RP прямо из группового адреса IPv6. Одинаковая формула давала согласованный кандидат, но не превращала вычисление в свидетельство доступного и работающего узла.
История
Фильтр можно было менять по одному источнику — или заменить целиком одним вызовом.
RFC 3678 не заставлял приложения multicast-приёма осваивать новый словарь членства в группах. Прежние вызовы остались на месте, а для изменения фильтра источников появились два способа: поправить один источник или заменить весь фильтр за одну операцию.
История
Получатель управлял скоростью, не отправляя отчётов отправителю: RFC 3738
В 2004 году WEBRC предложил контур управления перегрузкой в многоадресной передаче, которому не требовались индивидуальные отчёты каждого получателя отправителю. Получатель сам измерял свой путь и выбирал скорость приёма, выражая это решение через подключение к группам…
IETF
Прокси правильно свёл отчёты IGMPv3. Источники данных всё равно слились
Когда один частный узел вступает в группу, а другой почти одновременно выходит, простое чередование их сообщений может создать неверную последовательность для внешней стороны. RFC 5135 требует агрегировать состояние в прокси. Но даже безупречная агрегация не решает другую задачу…
IETF
Манифест подтвердил пакеты. Приложение всё ещё могло их отвергнуть.
В построенном примере клиент получил по доверенному каналу упорядоченный манифест и сверил каждый пакет multicast с его хешем. Происхождение и последовательность совпали. Но объект относился к другой версии запроса, а приложение не имело права его использовать. Криптографический…
История
Первый пакет должен был прийти до появления своей ветви с меткой: RFC 3353
Экономия меток казалась очевидной: пока multicast-группа молчит, не надо строить для неё LSP. Но первый пакет попадал в логическую ловушку. Нижестоящий маршрутизатор должен был увидеть трафик и запустить новую ветвь, хотя на втором уровне этот трафик мог прийти только по уже…
История
Модули можно было повторно использовать — и вместе потерпеть сбой: RFC 3269
Надёжной многоадресной передаче было недостаточно просто собрать повторно используемые части. RFC 3269 потребовал от каждого блока RMT обозначать свои границы и зависимости, а от полной инстанциации протокола — объяснять, как эти части соединены.
IETF
Получатель заметил отказ, но дошло ли извещение до источника?
У края дерева BIER можно достоверно зафиксировать потерю контрольных пакетов и всё же не иметь подтверждения, что о ней узнал входной маршрутизатор. Двенадцатая редакция проекта BIER BFD подробнее описывает обратное извещение и тем самым разделяет три события: обнаружение, приём…
История
Группа multicast для π из RFC 3091 не была адресом IPv4
RFC 3091 предлагал собирать π из потока цифр, индексированных ответов UDP или multicast-рассылки. Но указанная группа multicast не имела допустимого представления в IPv4, а TCP- и UDP-порты из того же документа превышали разрядность полей, которые должны были их передавать.
История
Уведомления продолжились без Directory Agent, но новые службы могли остаться незамеченными: RFC 3082
RFC 3082 предлагал заменить повторные опросы уведомлениями об изменениях. В процедуре восстановления видна более тонкая асимметрия: агенты служб, уже узнавшие о подписке, могут продолжать рассылку, а новый агент может так и не узнать, что кто-то ждёт сообщения.
IETF
Шифр подтверждает запись, но не право на адрес
GAAP-25 усиливает защиту заявки на multicast-адрес: зашифрованный Claim должен быть не только секретным, но и целостным. Однако владение общим ключом не превращается в полномочие распределять ресурс. Для эксплуатации это различие важнее самого криптографического маркера.
IETF
GAAP-25 отделяет протокол от иллюстративного Python API
Пример кода способен незаметно превратиться в «обязательную» часть спецификации, если разработчики копируют его без оговорок. Новая редакция GAAP прямо ограничивает такую трактовку: общим для участников должен быть обмен Claim, а не внутренний интерфейс приложения.
История
Таблица показывала участников. Строку мог создать сам менеджер: RFC 3019
RFC 3019 сделал состояние IPv6 multicast доступным через SNMP. Но та же MIB разрешала создавать и удалять строки, объявлять локальное членство и менять таймеры. Строка подтверждала представление агента, а не независимо присутствие удалённого слушателя или доставку данных.
История
Реплики совпали. Но клиентам всё равно пришлось вернуться: RFC 2443
В конце 1990-х ATM уже мог переносить IP multicast, однако клиенту по-прежнему требовалась служба, знающая состав групп. RFC 2443 позволил нескольким серверам MARS совместно хранить это состояние. Самое важное правило проявлялось при отказе: если исходный сервер переставал…