RFC 3390 Increasing TCP’s Initial Window

Network Working Group                                          M. Allman
Request for Comments: 3390                                  BBN/NASA GRC
Obsoletes: 2414                                                 S. Floyd
Updates: 2581                                                       ICIR
Category: Standards Track                                   C. Partridge
                                                        BBN Technologies
                                                            October 2002

 

Увеличение начального окна TCP

Increasing TCP’s Initial Window

PDF

Статус документа

Документ содержит спецификацию стандартного протокола для сообщества Internet и является приглашением к дискуссии в целях развития и совершенствования протокола. Сведения о стандартизации и состоянии данного протокола можно найти в документе Internet Official Protocol Standards (STD 1). Допускается свободное распространение данного документа.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

Этот документ задает необязательный стандарт для расширения дозволенного начального окна TCP с 1 или 2 сегментов приблизительно до 4K байт, взамен требований RFC 2414. В документе рассматриваются преимущества и недостатки в результате увеличения начального размера окна, а также обсуждаются эксперименты и модели, показывающие, что увеличение начального размера окна не ведет к коллапсу насыщения. В дополнение к этому документ содержит рекомендации для разработчиков.

Уровни требований

Ключевые слова «MUST» (необходимо), «MUST NOT» (недопустимо), «REQUIRED» (требуется), «SHALL» (следует), «SHALL NOT» (не следует), «SHOULD» (следует), «SHOULD NOT» (не следует), «RECOMMENDED» (рекомендуется), «MAY» (возможно) и «OPTIONAL» (необязательно) в данном документе трактуются в соответствии с RFC 2119 [RFC2119].

1. Изменение протокола TCP

Этот документ отменяет действие [RFC2414] и вносит изменения в [RFC2581], задавая увеличение верхнего предела начального размера окна TCP с 1 или 2 сегментов до 2 — 4 сегментов. В большинстве случаев это приводит к использованию начального размера окна приблизительно 4 кбайт (хотя с учетом разрешенного размера сегментов начальное окно размером в 2 сегмента может существенно превысить 4 кбайт).

Более точно верхнюю границу начального размера окна можно рассчитать с помощью выражения (1).

min (4*MSS, max (2*MSS, 4380 байт)) (1)

Примечание. Передача пакета размером 1500 байтов говорит о максимальном размере сегмента (MSS) 1460 байтов (в предположении отсутствия опций IP и TCP). Следовательно, ограничение MSS для начального окна значением 4380 байтов позволяет отправителю в общем случае передать изначально три сегмента, используя для них пакеты размером 1500 байтов.

Если верхняя граница начального размера окна задается на основе MSS, возможны три варианта:

       Если (MSS <= 1095 байтов)
           то win <= 4 * MSS;
       если (1095 байтов < MSS < 2190 байтов)
           то win <= 4380;
       Если (2190 байтов <= MSS)
           то win <= 2 * MSS;

Указанные значения начального размера окна являются рекомендуемыми — TCP может работать с окном большего размера. Однако мы предполагаем, что большинство реализаций TCP общего назначения выберет использование большего начального размера окна насыщения на основе уравнения (1).

Эти значения верхней границы начального окна отличаются от требований RFC 2581 [RFC2581], где сказано, что окно насыщения инициализируется с размером 1 или 2 сегмента.

Это изменение применяется к начальному окну соединения в течение первого периода кругового обхода (RTT1) при передаче данных вслед за трехэтапным согласованием TCP. Ни в сегментах SYN/ACK, ни в подтверждениях (ACK) в процессе треэтапного согласования размер начального окна не следует увеличивать сверх значения, заданного уравнением (1). Если сегмент SYN или SYN/ACK теряется, начальное окно, используемое отправителем после корректной передачи SYN должно быть равно 1 сегменту, содержащему MSS байтов.

Реализации TCP используют процедуру замедленного старта в трех разных ситуациях: (1) при старте нового соединения (начальное окно), (2) при восстановлении передачи после продолжительного бездействия (окно рестарта) и (3) при восстановлении передачи после тайм-аута повтора (окно потерь). Описанные в этом документе изменения оказывают влияние на начальное окно. Опционально TCP может установить для окна рестарта минимальное из значений начального окна и текущего cwnd (иными словами, использование большего значения окна рестарта никогда не должно приводить к увеличению cwnd). Предложенные здесь изменения не влияют на окно потерь, размер которого остается равным 1 сегменту, содержащему MSS байтов (чтобы обеспечить минимально возможный размер окна в случае некоторого насыщения).

2. Вопросы реализации

Когда увеличенное начальное окно реализовано вместе с Path MTU Discovery [RFC1191] и определено, что планируемое для использования значение MSS слишком велико, размер окна насыщения cwnd следует уменьшить для предотвращения выброса большого числа мелких сегментов. Конкретно cwnd следует уменьшить пропорционально снижению размера сегмента (поделить на отношение старого размера сегмента к новому размеру).

При реализации увеличенного начального окна вместе с Path MTU Discovery [RFC1191] возможна установка флага DF2 во всех сегментах начального окна или в одном сегменте этого окна. Вопрос выбора лучшего из этих вариантов еще не решен — будем надеяться, что опыт реализации поможет определиться с выбором. В первом случае, если начальные пакеты окажутся слишком велики, все эти пакеты будут отброшены в сети, поскольку их фрагментация запрещена флагом DF. Во втором случае, если пакеты окажутся слишком велики, все пакеты, кроме одного, будут фрагментированы в сети. Для второго случая установка флага DF в последнем сегменте начального окна обеспечивает минимальную вероятность повтора передачи по причине избыточного размера начального сегмента, поскольку в этом случае минимизируется вероятность доставки дубликатов ACK, включающей механизм Fast Retransmit. Однако вопросам взаимодействия увеличенного начального окна и механизма Path MTU Discovery требуется уделить дополнительное внимание.

Увеличенное начальное окно, описанное в этом документе, не предназначено для того, чтобы web-браузеры открывали множество одновременных соединений TCP в одном большом начальном окне. Когда браузер открывает одновременные соединения TCP с одним адресатом, он использует механизмы контроля насыщения TCP [FF99], независимо от размера начального окна. Использование этих механизмов вместе с увеличенным начальным окном оказывает дополнительное «давление» на прочий трафик в сети. Мы предлагаем использовать протокол HTTP/1.1 [RFC2068] (возобновляющиеся соединения TCP и конвейеры) в качестве средства повышения эффективности работы WEB.

3. Преимущества увеличения начального размера окна

  1. Когда начальное окно имеет размер 1 сегмент, получатель, использующий отложенные подтвреждения [RFC1122], вынужден ждать тайм-аута прежде, чем генерировать ACK. При начальном окне размером не менее 2 сегментов получатель будет генерировать ACK после прибытия второго сегмента данных. Это избавляет от необходимости ожидания тайм-аута (часто до 200 мсек и возможно до 500 мсек [RFC1122]).

  2. Для соединений, передающих незначительный объем данных, увеличенное начальное окно снижает время передачи (в предположении невысокой вероятности отбрасывания пакетов). Для многих почтовых транзакций (SMTP [Pos82]) и просмотра web (HTTP [RFC1945, RFC2068]) объем передаваемой информации составляет менее 4K байт и увеличенный размер начального окна будет снижать время передачи данных до одного периода RTT.

  3. Для соединений, которые способны использовать большое окно насыщения, предлагаемое изменение позволяет сэкономить до 3 периодов RTT и тайм-аута отложенных подтверждений в фазе замедленного старта. Это будет особенно полезно для широкополосных соединений со значительными задержками (например, через спутниковый канал).

4. Недостатки увеличения начального размера окна для соединения

В загруженных средах, особенно на маршрутизаторах с высоким уровнем насыщения, в частности, для маршрутизаторов с предубеждением к пикам трафика (как в типичных очередях Drop Tail), для соединения TCP может оказаться лучше использовать начальное окно размером в один сегмент. Существуют ситуации, когда соединение TCP, использующее замедленный старт с начальным окном размером в 1 сегмент, может обойтись без отбрасывания сегментов, а соединение с начальным окном в 4 сегмента может столкнуться с необходимостью повтора передачи по причине неспособности маршрутизатора обрабатывать незначительные пики трафика. Это может приводить к ненужным повторам передачи по тайм-ауту. Для соединений с большим окном, способным к восстановлению без тайм-аута повторной передачи, это может приводить к слишком раннему переходу от фазы замедленного старта к фазе увеличения окна. Такое преждевременное отбрасывание сегментов может возникать в незагруженных сетях с достаточной емкостью буферов или в сетях со средним уровнем насыщения, где перегруженные маршрутизаторы используют активное управления очередями (например, Random Early Detection [FJ93, RFC2309]).

Соединения TCP могут получать преимущества от увеличения начального размера окна даже если это увеличение приведет к преждевременному отбрасыванию сегмента. Это будет наблюдаться, если (1) соединение TCP восстанавливается после отбрасывания сегмента без тайм-аута повторной передачи и (2) размер окна насыщения для соединения TCP ограничен малым значением по причине перегрузки в сети или малого окна, анонсируемого получателем.

5. Недостатки увеличения начального размера окна для сети

Для случаев потенциальной перегрузки будем раздельно рассматривать две потенциально опасных для сети ситуации. Первая связана со случаем, когда большое число сегментов перегруженного канала являются дубликатами сегментов, которые уже были получены приемной стороной. Вторая ситуация возникает, когда большое число сегментов в перегруженных каналах будет позднее отброшено до поступления их конечному получателю.

В плане негативного влияния на остальной трафик в сети потенциальным недостатком увеличенного начального окна будет то, что в этом случае увеличивается общая частота отбрасывания пакетов в сети. Ниже все эти негативные факторы рассматриваются более подробно.

Дубликаты сегментов

Как отмечено выше увеличенное начальное окно может иногда приводить к отбрасыванию сегмента из этого окна, хотя этот сегмент мог бы не оказаться отброшенным, если бы отправитель начал процедуру замедленного старта с окном размером в 1 сегмент. Однако в Приложении A показано, что даже в таких случаях увеличение начального размера окна не будет приводить к передаче большого числа дубликатов сегментов.

Сегменты, которые будут отброшены впоследствии

Насколько увеличение размера начального окна для TCP будет увеличивать в перегруженных каналах число сегментов, которые будут отброшены на пути к получателю? Эта проблема возникает только для соединений с множеством перегруженных каналов, где некоторые сегменты могут занимать дефицитную полосу в первом перегруженном канале на пути и потом оказаться отброшенными на следующих этапах доставки.

Во-первых, многие соединения TCP включают единственный перегруженный канал на пути через сеть. Отброшенные сегменты таких соединений не будут впустую «поглощать» дефицитную полосу пропускания и не будут вносить вклада в возникновение коллапса насыщения.

Однако некоторые пути могут включать множество перегруженных каналов и отбрасываемые сегменты начального окна могут потреблять полосу первых перегруженных каналов, а потом отбрасываться на последующих перегруженных участках пути. Поскольку рост скорости отбрасывания пакетов не зависит от размера начального окна TCP, проблема отбрасывания сегментов, которые уже прошли через перегруженные каналы до их отбрасывания в сети, будет одинакова для соединений TCP, независимо от того, будет начальное окно включать 4 сегмента или 1.

Рост частоты отбрасывания пакетов

Для сети с высокой частотой отбрасывания сегментов увеличение размера начального окна TCP может приводить к дополнительному росту частоты отбрасывания сегментов. Это связано отчасти с тем, что маршрутизаторы с механизмом управления очередями Drop Tail сталкиваются с трудностями при возникновении всплесков трафика во время перегрузки. Однако с учетом отсутствия корреляций в прибытии сегментов разных соединений TCP увеличение размера начального окна TCP не будет существенно повышать частоту отбрасывания сегментов. Основанное на результатах моделирования обсуждение этого вопроса приведено в параграфе 7.2.

Эти потенциальные опасности для сетей исследовались на моделях и в экспериментах, описанных ниже. На наш взгляд опасность коллапса насыщения в современной сети Internet существует (см. [FF99], где обсуждаются вопросы связанные с коллапсом насыщения в результате расширения использования соединений UDP без сквозного контроля насыщения), увеличение размера начального окна TCP до 4 Кбайт не ведет к эскалации опасности.

6. Взаимодействие с таймером повтора передачи

Использование увеличенного начального «всплеска» данных может усугубить имеющиеся проблемы за счет возникновения ложных тайм-аутов повтора на низкоскоростных путях в предположении использования стандартного алгоритма TCP для определения тайм-аута повтора (RTO3) [RFC2988]. Проблема заключается в том, что на низкоскоростных путях, где время передачи составляет значительную часть периода кругового обхода, мелкие пакеты, используемые для организации соединения TCP, не обеспечивают корректной оценки RTO. При передаче первого окна данных отсчет таймера повторной передачи на стороне отправителя может завершиться до получения подтверждений для пакетов первого окна. По прибытии таких подтверждений таймер в общем случае сбрасывается. Таким образом, при отсутствии подтверждений тайм-аут будет наступать по прошествии по крайней мере 1 секунды, в соответствии со значением RTO, рекомендуемым в RFC 2988.

В качестве примера рассмотрим канал с полосой 9,6 кбит/с. Начальное измерение RTT будет давать время кругового обхода около 67 мсек, если мы будем просто рассматривать передачу двух пакетов (SYN и SYN-ACK) размером по 40 байтов. Используя оценку RTO в соответствии с [RFC2988], мы получим начальное значение RTO = 201 мсек (67 + 4*(67/2)). Однако это значение RTO будет округляться до 1 секунды в соответствии с RFC 2988. Предположим, что передается начальное окно, содержащее один или несколько пакетов по 1500 байтов (1460 байтов данных и заголовки). Каждый пакет будет передаваться примерно 1,25 сек. Следовательно, время RTO наступит раньше, чем будет получен сегмент ACK для первого пакета, что приведет к возникновению ложного тайм-аута. В этом случае увеличенное начальное окно размером в 3 или 4 пакета усугубит проблемы, связанные с ложным тайм-аутом.

Одним из способов решения этой проблемы является повышение консервативности алгоритма RTO. В начальном окне, например, можно обновлять значение RTO при получении каждого подтверждения. Кроме того, если отсчет таймера повтора завершается для потерянного пакета из первого окна данных, можно задержать экспоненциальное снижение значения таймера повтора по крайней мере до одного корректного измерения RTT, включающего принятный пакет.

Другой метод заключается в отказе от измерения RTT в процессе организации соединения и сохранении принятого по умолчанию RTO до тех пор, пока измерение не будет проведено с использованием сегмента данных TCP и соответствующего сегмента ACK. Хотя этот метод позволяет предотвратить ненужные повторы передачи, он может также замедлить передачу данных в случаях, когда пакеты будут теряться до установки начального значения RTO. Использование ограниченной передачи [RFC3042] при восстановлении соединения TCP после потери с помощью ускоренного повтора вместо ожидания таймера RTO позволяет снизить негативное влияние, вызванное использованием принятого по умолчанию большого значения RTO на этапе передачи начального окна данных.

Эта реализация оставляет решение вопроса выбора действий (или бездействия) в части установки значения RTO при использовании увеличенного начального окна за разработчиками. Однако рекомендуется воздерживаться от измерения RTT в процессе трехэтапного согласования с сохранением принятого по умолчанию значения RTO до тех пор, пока не будет определено значение RTT, включающее передачу пакета данных. Кроме того, рекомендуется использовать для TCP ограниченную передачу [RFC3042].

7. Типичные пиковые уровни для трафика TCP

Более крупные начальные окна TCP не будут значительно увеличивать всплески трафика TCP в сегодняшней сети Internet, поскольку такой трафик уже достаточно «взрывной». Всплески в 2 и 3 сегмента уже стали нормальными для TCP [Flo97]; задержавшееся подтверждение ACK (покрывающее два ранее не подтвержденных сегмента), полученное в результате предотвращения перегрузок сдвигает окно насыщения и вызывает передачу двух сегментов. Такое же задержанное подтверждение ACK, полученное во время замедленного старта, сдвигает окно на два сегмента и увеличивает его на один сегмент, что приводит к передаче трех сегментов сразу. Всплески из 4 или 5 сегментов не столь типичны, но и не редки. В предположении задержки ACK одно отброшенное подтверждение ACK вынуждает последующее подтверждение ACK покрывать 4 ранее не подтвержденных сегмента. В процессе предотвращения перегрузки это вызывает всплеск из четырех сегментов, а при замедленном старте — из пяти.

Готовится множество предложений, способных ослабить проблемы производительности, вызываемые умеренными всплесками трафика. Одно из таких предложений включает развертывание более скоростных каналов в некоторых частях сети, где всплески трафика в 4 Кбайта могут представлять незначительную часть данных. Второе изменение относится к маршрутизаторам с достаточным объемом буферов и состоит в развертывании механизмов управления очередями типа RED, которые обеспечивают устойчивость к непродолжительным всплескам трафика.

8. Результаты моделирования и экспериментов

8.1 Исследование соединений TCP с увеличенным начальным окном

В этом параграфе рассмотрено моделирование и эксперименты по влиянию больших начальных окон на соединения TCP. В первой группе экспериментов изучалась производительность на спутниковых каналах. Большие начальные окна показали повышение производительности соединений TCP на спутниковых каналах [All97b]. В этих экспериментах начальное окно в 4 сегмента (MSS 512 байтов) повышало производительность до 30% (в зависимости от размера передачи). В [KAGT98] показано, что использование больших начальных окон снижает время передачи в тестах HTTP через спутниковые каналы ACTS. Моделирование большого числа транзакций HTTP через среду HFC4 показывает, что увеличение начального размера окна уменьшает время загрузки страниц WWW [Nic98].

Во второй группе экспериментов изучалась работа TCP на коммутируемых модемных каналах. На соединениях 28,8 кбит/с5 [All97a, AHO98] 4-сегментное начальное окно снижало время передачи файла размером 16 Кбайт примерно на 10% без роста частоты потери пакетов. В работе [RFC2416] исследовалось влияние использования увеличенного начального окна при подключении хоста по медленному модемному каналу к маршрутизатору с буфером на 3 пакета. По результатам исследования отмечено, что увеличение начального размера окна не оказывает негативного влияния на производительность TCP.

В работе [All00] показано, что доля соединений на конкретном web-сервере, сталкивающихся с потерей пакетов в начальном окне передачи данных, возрастает с увеличением размера начального окна насыщения. Однако это увеличение соответствует потерям, ожидаемым в результате передачи в сеть существенного объема трафика.

8.2 Изучение сетей, использующих увеличенный размер начального окна

В этом параграфе рассматриваются экспериментальные и модельные исследования влияния большого окна TCP на другие соединения в том же пути. Эксперименты [All97a, AHO98] показали, что передачи по 16 Кбайт на 100 хостов Internet с 4-сегментным начальным окном приводят к незначительному росту частоты отбрасывания пакетов (0,04 сегмента на передачу). Частота потерь возрастала незначительно, а время передачи уменьшалось приблизительно на 25% при использовании начального окна размером 4 сегмента (MSS 512 байт) по сравнению с окном в 1 сегмент.

Моделирование в [RFC2415] было связано с изучением воздействия увеличения начального окна на одновременный сетевой трафик. В этой работе потоки HTTP и FTP использовали общий перегруженный шлюз (число потоков HTTP и FTP варьировалось от случая к случаю). Для каждого случая определялась общая загрузка канала и частота отбрасывания пакетов, средняя задержка при загрузке страницы web и скорость передачи FTP. Увеличение начального окна обычно приводило к росту пропускной способности, незначительному росту уровня потери пакетов и повышению общей производительности сети. За исключением одного случая увеличение начального окна повышало частоту потерь не более, чем на 1% по сравнению с 1-сегментным начальным окном — потери достигали 3,5% при односегментном окне и 4,5% — при 4-сегментном. Вывод этой работы заключался в том, что увеличение начального окна TCP до трех пакетов (4380 байтов) повышает производительность сети.

Morris [Mor97] исследовал влияние увеличенных начальных окон в тяжело нагруженной сети для передач размером 20 Кбайт. Частота потерь в сетях, где все соединения TCP использовали начальное окно в 4 сегмента, была на 1-2% выше чем для 1-сегментных окон. Эта зависимость сохранялась для случаев, когда потери при 1-сегментном начальном окне составляли от 1% до 11%. Кроме того, в сетях с начальным окном в 4 сегмента отправители TCP дольше ждали тайм-аута RTO для повтора передачи по сравнению с 1-сегментным окном. Это время ожидания является простоем, когда через соединение не передается данных. Результаты показывают, что в сильно загруженной среде, где все соединения используют общий узкий канал, увеличение начального окна может приводить к заметному росту числа потерь и тайм-аутов повтора.

9. Вопросы безопасности

В этом документе обсуждается начальный размер окна насыщения, разрешенный для соединений TCP. Изменение этого размера не меняет состояния безопасности TCP.

10. Заключение

Этот документ задает незначительное изменение TCP, которое будет очевидно полезным для краткосрочных соединений TCP, а также для соединений через каналы с большим значением RTT (обеспечивается экономия времени в несколько RTT на этапе замедленного старта).

11. Благодарности

Мы благодарим Vern Paxson, Tim Shepard, участников списка рассылки End-to-End-Interest и членов рабочей группы IETF TCP Implementation за обсуждение проблемы и отклики на этот документ.

12. Литература

[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. ACM Computer Communication Review, 28(3), July 1998. «http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps«6.

[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting — TCP Implementations WG. December, 1997. Washington, DC.

[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master’s thesis, Ohio University, June 1997.

[All00] Mark Allman. A Web Server’s View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000.

[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.

[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. IEEE/ACM Transactions on Networking, August 1999. URL «http://www.icir.org/floyd/end2end-paper.html«.

[FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.

[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.

[Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.

[Flo97] Floyd, S., Increasing TCP’s Initial Window. Viewgraphs, 40th IETF Meeting — TCP Implementations WG. December, 1997. URL «ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps«.

[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems. URL «http://roland.lerc.nasa.gov/~mallman/papers/nash98.ps«.

[Mor97] Robert Morris. Частное сообщение, 1997. Указано только с целью благодарности.

[Nic98] Kathleen Nichols. Improving Network Simulation With Feedback, Proceedings of LCN 98, October 1998. URL «http://www.computer.org/proceedings/lcn/8810/8810toc.htm«.

[Pos82] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 8217, August 1982.

[RFC1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU Discovery», RFC 1191, November 1990.

[RFC1945] Berners-Lee, T., Fielding, R. and H. Nielsen, «Hypertext Transfer Protocol — HTTP/1.0», RFC 1945, May 1996.

[RFC2068] Fielding, R., Mogul, J., Gettys, J., Frystyk, H. and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, January 1997.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, «Recommendations on Queue Management and Congestion Avoidance in the Internet», RFC 2309, April 1998.

[RFC2414] Allman, M., Floyd, S. and C. Partridge, «Increasing TCP’s Initial Window», RFC 2414, September 1998.

[RFC2415] Poduri, K. and K. Nichols, «Simulation Studies of Increased Initial TCP Window Size», RFC 2415, September 1998.

[RFC2416] Shepard, T. and C. Partridge, «When TCP Starts Up With Four Packets Into Only Three Buffers», RFC 2416, September 1998.

[RFC2581] Allman, M., Paxson, V. and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC2821] Klensin, J., «Simple Mail Transfer Protocol», RFC 2821, April 2001.

[RFC2988] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, «Enhancing TCP’s Loss Recovery Using Limited Transmit», RFC 3042, January 2001.

[RFC3168] Ramakrishnan, K.K., Floyd, S. and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

Приложение A — Дубликаты сегментов

В современных средах (без ECN8 [Flo94] [RFC2481]) все TCP используют факты отбрасывания сегментов, как индикацию от сети о достижении передела пропускной способности. В этом документе утверждается, что увеличение начального размера окна не должно приводить к росту числа передаваемых отправителем повторов для пакетов, которые уже приняты получателем.

Если из начального окна отбрасывается один сегмент, восстановление TCP может пойти тремя путями: (1) замедленный старт с начальным окном в один сегмент, как после тайм-аута повтора или ускоренного повтора в Tahoe TCP; (2) быстрое восстановление без селективных подтверждений (SACK9), как после трех дубликатов ACK в Reno TCP; (3) быстрое восстановление с SACK для TCP, где отправитель и получатель поддерживают опцию SACK [MMFR96]. Во всех трех случаях отбрасывание сегмента из начального окна не приводит к передаче дубликатов (т. е., сегментов, которые уже были приняты получателем). Отметим, что для TCP, передающего 4 сегмента по 512 байтов в начальном окне, отбрасывание одного сегмента не будет требовать тайм-аута повтора и восстановление может быть выполнено с помощью алгоритма Fast Retransmit (если отсчет таймера повтора не завершился раньше). При отбрасывании одного сегмента из начального окна в 3 сегмента восстановление возможно с помощью алгоритма ускоренного повтора в зависимости от того, какой из сегментов был отброшен и используются ли незадержанные подтверждения ACK. Например, отбрасывание первого из трех сегментов начального окна всегда будет требовать ожидания тайм-аута в отсутствии Limited Transmit [RFC3042]. Однако отбрасывание третьего сегмента всегда позволяет восстановление с помощью алгоритма ускоренного повтора, если подтверждения ACK не терялись.

Рассмотрим случай, когда начальное окно имеет размер от 2 до 4 сегментов и по крайней мере два из этих сегментов отбрасываются. Если отброшены все сегменты начального окна, ясно, что возникновение дубликатов просто невозможно, поскольку получатель еще не принял ничего (вопрос расхода дефицитной полосы, связанного с отброшенными сегментами, был рассмотрен в разделе 5).

При отбрасывании двух сегментов их 3-сегментного начального окна отправитель будет передавать дубликат сегмента только в том случае, когда отброшены два первых сегмента из трех и отправителем не было получено пакета с опцией SACK, подтверждающей третий сегмент.

При отбрасывании двух сегментов из 4-сегментного начального окна проверка 6 возможных вариантов (не проводится здесь) показывает, что в зависимости от номеров отброшенных пакетов в отсутствии SACK отправитель может передать один сегмент-дубликат. Вариантов с передачей двух дубликатов не возникает.

При отбрасывании трех сегментов из 4-сегментного начального окна в отсутствии SACK возможна отправка одного дубликата (в зависимости от номеров отброшенных сегментов).

Таким образом, при отсутствии SACK и отбрасывании множества сегментов из начального окна возможны ситуации с передачей одного сегмента-дубликата. Передачи нескольких дубликатов не возникает ни в одном случае. В результате можно сделать вывод о том, что вероятность появления на приемной стороне сегментов-дубликатов в результате увеличения начального окна должна быть достаточно мала.

Адреса авторов

Mark Allman

BBN Technologies/NASA Glenn Research Center

21000 Brookpark Rd

MS 54-5

Cleveland, OH 44135

EMail: mallman@bbn.com

http://roland.lerc.nasa.gov/~mallman/

Sally Floyd

ICSI Center for Internet Research

1947 Center St, Suite 600

Berkeley, CA 94704

Phone: +1 (510) 666-2989

EMail: floyd@icir.org

http://www.icir.org/floyd/

Craig Partridge

BBN Technologies

10 Moulton St

Cambridge, MA 02138

EMail: craig@bbn.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Round trip time.

2Don’t Fragment — не фрагментировать.

3Retransmission timeout.

4Hybrid fiber coax.

5В оригинале ошибочно указана скорость 28,8 бит/с (см. http://www.rfc-editor.org/errata_search.php?rfc=3390&eid=4569). Прим. перев.

6Статья по указанной в тесте ссылке не доступна. Можно воспользоваться другой ссылкой. Прим. перев.

7Этот документ признан устаревшим и заменен RFC2821, который, в свою очередь был заменен RFC 5321. Прим. перев.

8Explicit Congestion Notification — явное уведомление оп насыщении.

9Selective acknowledgment.




RFC 3376 Internet Group Management Protocol, Version 3

Network Working Group                                        B. Cain
Request for Comments: 3376                           Cereva Networks
Obsoletes: 2236                                           S. Deering
Category: Standards Track                                I. Kouvelas
                                                       Cisco Systems
                                                           B. Fenner
                                                AT&T Labs - Research
                                                      A. Thyagarajan
                                                            Ericsson
                                                        October 2002

Протокол управления группами Internet (IGMP), версия 3

Internet Group Management Protocol, Version 3

PDF

Статус документа

Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования. Текущее состояние стандартизации и статус протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

В этом документе описана версия 3 протокола управления группами Internet — IGMPv31. Протокол IGMP используется системами IPv4 для информирования соседних групповых маршрутизаторов о своих группах IP. В третьей версии IGMP добавлена поддержка фильтрации по источнику (source filtering), позволяющая системе сообщить о своей заинтересованности в получении группового трафика, направленного по данному групповому адресу, только от указанных отправителей или от всех, кроме указанных. Эта информация может применяться протоколами групповой маршрутизации для предотвращения доставки групповых пакетов от указанных отправителей в сети, где нет заинтересованных получателей.

Данных документ отменяет действие RFC 2236.

Оглавление

Исключено в версии HTML.

1. Введение

Протокол IGMP используется системами IPv4 (хостами и маршрутизаторами) для передачи соседним групповым маршрутизаторам сведений о принадлежности к их группам IP. Отметим, что групповые маршрутизаторы IP сами по себе могут быть членами multicast-групп и в этом случае выступают в протоколе, как участники маршрутизации (multicast router part) для сбора сведений о принадлежности к группам, используемых протоколом групповой маршрутизации, и члены групп (group member part) для информирования самого себя и других соседних маршрутизаторов о принадлежности к группам.

IGMP используется также для других функций управления групповой адресацией IP с применением сообщений, типы которых отличаются от сообщений о принадлежности к группам. В этом документе рассматриваются лишь функции и сообщения, связанные с принадлежностью к группам.

Этот документ задает версию 3 протокола IGMP. Версия 1, описанная в [RFC-1112], была первой широко распространенной версией, получившей статус стандарта Internet. В версии 2, заданной [RFC-2236], была добавлена поддержка low leave latency, т. е. снижения времени, в течение которого групповой маршрутизатор может принимать решение об отсутствии членов конкретной группы в подключенной сети. В версии 3 добавлена поддержка фильтрации источников, позволяющая системе указать свою заинтересованность в получении группового трафика только от указанных отправителей, как требуется для поддержки [SSM2], или от всех отправителей кроме указанных, передаваемого по указанному групповому адресу. Версия 3 предполагает интероперабельность с версиями 1 и 2.

Механизм MLD3 аналогичным способом используется системами IPv6. MLD версии 1 [MLD] реализует функциональность IGMP версии 2, а MLD версии 2 [MLDv2] — функциональность IGMP версии 3.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC-2119]. В переводе эти слова выделяются полужирным шрифтом.

2. Сервисный интерфейс для запроса получения IP Multicast

В IP-системах имеется (по крайней мере, концептуально) служебный интерфейс, используемый протоколами вышележащих уровней для запросу на уровне IP разрешения или запрета приема пакетов, направленных на указанный групповой адрес IP. Для полного использования возможностей IGMPv3 этот интерфейс должен поддерживать операцию:

IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list )

где:

  • socketзависящий от приложения параметр, используемый для идентификации запрашиваемых в системе объектов (например, программ или процессов), примером могут служить системные вызовы BSD Unix.

  • interface — локальный идентификатор сетевого интерфейса, для которого разрешается или запрещается восприятие указанного группового адреса. Интерфейс может быть физическим (например, Ethernet) или виртуальным (например, оконечная точка виртуального соединения Frame Relay или «туннеля» IP-in-IP). Реализация может разрешать специальное значение unspecified (не задано) в качестве параметра interface — в этом случае запрос будет применяться к основному (primary) или используемому по умолчанию (default) интерфейсу системы (возможно, организованному в системной конфигурации). Если восприятие группового адреса желательно для нескольких интерфейсов, IPMulticastListen вызывается для каждого из них.

  • multicast-address — групповой адрес IP или группа, к которой относится запрос. Если на данном интерфейсе желательно принимать более одного адреса, IPMulticastListen вызывается для каждого из таких адресов.

  • filter-mode — режим фильтрации. Параметр может принимать значение INCLUDE (включить) или EXCLUDE (исключить). В режиме INCLUDE получение пакетов на заданный групповой адрес запрашивается только с адресов IP, указанных параметром source-list. В режиме EXCLUDE получение пакетов на данный групповой адрес желательно от всех отправителей, кроме указанных параметром source-list.

  • source-list — неупорядоченный (возможно, пустой) список индивидуальных адресов IP с которых желательно или не желательно (в соответствии с фильтром) принимать групповой трафик. Реализация может вносить ограничения на размер списка, но недопустимо ограничивать его значением меньше 64. При достижении предельного размера списка адресов служебный интерфейс должен возвращать сообщение об ошибке.

Для данной комбинации сокета, интерфейса и группового адреса в каждый момент времени может действовать только один режим фильтрации и список источников. Однако фильтр и список источников можно сменить последующими запросами IPMulticastListen для того же сокета, интерфейса и группового адреса. Каждый последующий запрос полностью отменяет предыдущие установки для указанного сокета, интерфейса и группового адреса.

В предыдущей версии IGMP фильтрация источников не поддерживалась и был простой сервисный интерфейс с операциями Join и Leave для разрешения и запрета приема по указанному групповому адресу (из всех источников) для данного интерфейса. Эквивалентные операции в новом сервисном интерфейсе приведены ниже.

Операции Join эквивалентен запрос

IPMulticastListen ( socket, interface, multicast-address, EXCLUDE, {} )

Операции Leave эквивалентен запрос

IPMulticastListen ( socket, interface, multicast-address, INCLUDE, {} )

где {} указывает пустой список источников.

Пример API, поддерживающего описанный выше служебный интерфейс, приведен в [FILTER-API].

3. Состояние восприятия группового трафика в системе

3.1. Состояние сокета

Для каждого сокета, который был указан в вызовах IPMulticastListen системе желательно сохранять запись о состоянии. Концептуально такая запись о состоянии сокета может иметь вид:

(interface, multicast-address, filter-mode, source-list)

Состояние сокета меняется при каждом вызове IPMulticastListen для сокета, как показано ниже:

  • если запрошен режим фильтрации INCLUDE и список источников пуст, при наличии элемента для запрошенного интерфейса и группового адреса этот элемент удаляется; при отсутствии такого элемента запрос игнорируется;

  • если запрошен режим фильтрации EXCLUDE или запрошенный список источников не пуст, при наличии элемента для запрошенного интерфейса и группового адреса он изменяется в соответствии с запрошенным режимом фильтрации и списком источников; если такого элемента нет, он создается с использовании заданных в запросе параметров.

3.2. Состояние интерфейса

В дополнение к состояниям приема группового трафика на уровне сокетов система также должна поддерживать или рассчитывать такое состояние для каждого из своих интерфейсов. Концептуально состояние представляет собой набор записей вида:

(multicast-address, filter-mode, source-list)

Для данного интерфейса существует не более одной записи на multicast-адрес. Состояние на уровне интерфейса выводится из состояний на уровне сокета, но может отличаться от него, когда разные сокеты используют разные режимы фильтрации и/или списки групповых адресов для того же группового адреса и интерфейса. В качестве примера предположим, сто приложение или процесс вызывает для сокета s1 операцию

IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} ),

запрашивающую прием на интерфейсе i пакетов, переданных по групповому адресу m, исходящих только с адресов a, b и c. Предположим, что другое приложение или процесс вызывает для сокета s2 операцию

IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} ),

запрашивающую прием на том же интерфейсе i пакетов, переданных по тому же групповому адресу m, исходящих только с адресов b, c и d. Для удовлетворения требований на обоих сокетах интерфейсу i нужно принимать пакеты, направленные по адресу m от любого из источников a, b, c и d. Таким образом, в этом примере состояние интерфейса i для группового адреса m имеет фильтр INCLUDE и список источников {a, b, c, d}.

После того, как групповой пакет был воспринят с интерфейса уровнем IP, он доставляется процессу или приложению, прослушивающему конкретный сокет, заданный состоянием восприятия группового трафика [и, возможно, другими условиями типа номера порта транспортного уровня, к которому привязан сокет]. В рамках приведенного выше примера если пакет приходит на интерфейс i и направлен по групповому адресу m от источника a, он будет доставлен на сокет s1, но не на сокет s2. Отметим, что сообщения IGMP Query и Report не фильтруются по источнику и всегда должны обрабатываться хостами и маршрутизаторами.

Фильтрация пакетов в зависимости от состояния приема группового трафика на сокете является новой функцией этого служебного интерфейса. Прежний сервисный интерфейс [RFC1112] не использовал фильтрации по состоянию сокета. Присоединение сокета просто присоединяло хост к группе через данный интерфейс и пакеты, направленные в данную группу, доставлялись всем сокетам, независимо от их реального присоединения.

Общее правило порождении состояния интерфейса из состояния сокета состоит в создании записи для группового адреса на интерфейсе для каждой различающейся пары (интерфейс — групповой адрес) во всех состояниях сокета. Для совпадающих пар (интерфейс — групповой адрес) выполняются следующие действия:

  • если любая из таких записей включает фильтр EXCLUDE, для интерфейса тоже устанавливается фильтр EXCLUDE, а список источников для интерфейсной записи будет пересечением списков источников во всех записях сокетов с фильтром EXCLUDE с исключением из него всех списков источников из записей сокета с фильтром INCLUDE. Например, если записи сокетов для группового адреса m и интерфейса i:

    s1: ( i, m, EXCLUDE, {a, b, c, d} )
    s2: ( i, m, EXCLUDE, {b, c, d, e} )
    s3: ( i, m, INCLUDE, {d, e, f} )

    соответствующая запись для интерфейса i будет:

    ( m, EXCLUDE, {b, c} )

    Если добавится четвертый сокет

    s4: ( i, m, EXCLUDE, {} )

    интерфейсная запись примет вид:

    ( m, EXCLUDE, {} )
  • если все записи имеют фильтр INCLUDE, для интерфейсной записи также устанавливается режим INCLUDE, а список источников для интерфейсной записи будет объединением списков источников из записей сокетов. Например, если сокеты для группового адреса m на интерфейсе i имеют вид

    s1: ( i, m, INCLUDE, {a, b, c} )
    s2: ( i, m, INCLUDE, {b, c, d} )
    s3: ( i, m, INCLUDE, {e, f} )

    запись для интерфейса i будет

    ( m, INCLUDE, {a, b, c, d, e, f} )
  • Реализациям недопустимо использовать интерфейсную запись EXCLUDE для представления группы, если все сокеты для этой группы используют фильтр INCLUDE. Если при расчете состояния для интерфейса достигнут предел доступных системных ресурсов, запросившему операцию приложению должно возвращаться сообщение об ошибке.

Приведенные выше правила порождения состояния для интерфейса используются вновь, если вызов IPMulticastListen изменяет состояние сокета путем добавления или изменения записи для состояния сокета. Отметим, что изменение состояния сокета не обязательно влечет за собой изменение состояния для интерфейса.

4. Форматы сообщений

Сообщения IGMP инкапсулируются в дейтаграммы IPv4 с номеров протокола IP 2. Каждое сообщение IGMP, описанное в этом документе, передается со значениями IP TTL = 1, IP Precedence = Internetwork Control (например, ToS 0xc0) и опцией IP Router Alert [RFC-2113] в заголовке IP. Типы сообщений IGMP, зарегистрированы IANA [IANA-REG], как описано в [RFC-3228].

В данном документе описаны два типа сообщений IGMP, относящихся к IGMPv3.

Номер типа (шестнадцатеричный)

Имя сообщения

0x11

Membership Query — запрос на включение в группу

0x22

Version 3 Membership Report — отчет о принадлежности (версия 3)

Реализации IGMPv3 должны также поддерживать перечисленные ниже сообщения для обеспечения взаимодействия с предыдущими версиями IGMP (см. раздел 7):

0x12

Version 1 Membership Report — отчет о принадлежности (версия 1) [RFC-1112]

0x16

Version 2 Membership Report — отчет о принадлежности (версия 2) [RFC-2236]

0x17

Version 2 Leave Report — отчет о выходе (версия 2) [RFC-2236]

Нераспознанные типы сообщений должны отбрасываться без уведомления. Новые версия или расширения IGMP, протоколов групповой маршрутизации и т. п. могут использовать дополнительные типы сообщений.

В этом документе (если явно не указано иное) термины Query и Report обозначают сообщения IGMP Membership Query и IGMP V3 Membership Report, соответственно.

4.1. Запрос о принадлежности к группе

Сообщения Membership Query передаются групповыми маршрутизаторами IP для запроса состояния приема группового трафика на соседних интерфейсах. Формат запроса показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x11  | Max Resp Code |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                              .                              -+
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code

Поле Max Resp Code задает максимальное время, задержки с отправкой отклика. Реальное значение разрешенной задержки определяется значением Max Resp Time, которое представляется в десятых долях секунды и определяется на основе Max Resp Code, как показано ниже:

если Max Resp Code < 128, Max Resp Time = Max Resp Code;

если Max Resp Code >= 128, Max Resp Code представляется десятичным значением с плавающей запятой в формате:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+
Max Resp Time = (mant | 0x10) << (exp + 3)

Малые значения Max Resp Time позволяют маршрутизаторам IGMPv3 подобрать leave latency (задержка между моментом выхода из группы последнего хоста и моментом, когда протокол маршрутизации уведомляется об отсутствии в группе кого-либо). Большие значения (особенно > 128) позволяют регулировать всплески трафика IGMP в сети.

4.1.2. Checksum

Поле контрольной суммы представляет собой 16-битовое дополнение до 1 суммы дополнений до 1 для всего сообщения IGMP (данные пакеты IP). При расчете контрольной суммы само значение поля Checksum предполагается нулевым. На приемной стороне контрольная сумма должна проверяться до начала обработки сообщения [RFC-1071].

4.1.3. Group Address

Поле Group Address содержит значение 0 для сообщений General Query и запрашиваемый групповой адрес IP для сообщений Group-Specific Query и Group-and-Source-Specific Query (см. параграф 4.1.9).

4.1.4. Resv (резерв)

Поле Resv устанавливается в 0 при передаче и игнорируется на приемной стороне.

4.1.5. Флаг S (подавление обработки Router-Side)

Установленный флаг S указывает всем промежуточным групповым маршрутизаторам, что выполнять обычные обновления таймеров, которые происходят при получении запросов, для этого случая не нужно. Однако этот флаг не отменяет выбор запрашивающего и обычную (host-side) обработку запроса, которая может потребоваться на маршрутизаторах, являющихся членами группы.

4.1.6. QRV

Если поле QRV4 отлично от 0, оно содержит значение [Robustness Variable], используемое запрашивающим (т. е., отправителем запроса). Если значение [Robustness Variable] у запрашивающего превышает 7 (максимум для поля QRV), устанавливается QRV = 0. Маршрутизаторы используют значение QRV из наиболее свежего запроса в качестве значения переменной [Robustness Variable], если это поле отлично от 0. При нулевом значении QRV получатели используют принятое по умолчанию (см. параграф 8.1) или заданное статически значение [Robustness Variable].

4.1.7. QQIC

Поле QQIC5 указывает [Query Interval], используемый запрашивающим. Реальный интервал 6QQI задается в секундах и определяется на основе кода QQIC, как показано ниже

если QQIC < 128, QQI = QQIC

если QQIC >= 128, QQIC представляется действительным числом с плавающей запятой в форме

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+

   QQI = (mant | 0x10) << (exp + 3)

Групповые маршрутизаторы, не являющиеся инициатором текущего запроса, устанавливают свое значение [Query Interval] в соответствии с QQI на основе наиболее свежего запроса, если значение QQI не равно 0. В последнем случае используется принятое по умолчанию значение [Query Interval], как указано в параграфе 8.2.

4.1.8. Number of Sources (N)

Поле Number of Sources (N) указывает число адресов источников, присутствующих в запросе. Это поле имеет значение 0 в запросах General и Group-Specific, а в запросах Group-and-Source-Specific отлично от 0. Число адресов ограничено значением MTU в сети, через которую передается сообщение Query. Например в сетях Ethernet значение MTU равно 1500, заголовок IP с опцией Router Alert занимает 24 октета, поля IGMP вместе с Number of Sources (N) — еще 12 октетов и для адресов источников остается 1464 октета, что позволяет включить 366 адресов (1464/4).

4.1.9. Source Address [i]

Поле Source Address [i] представляет собой вектор из n индивидуальных адресов IP, где значение n задано полем Number of Sources (N).

4.1.10. Дополнительные данные

Если поле Packet Length в заголовке IP принятого запроса указывает на присутствие дополнительных октетов данных, реализация IGMPv3 должна учитывать эти данные при вычислении контрольной суммы и сравнении с полем IGMP Checksum, в противном случае эти данные должны игнорироваться. При передаче сообщений Query реализациям IGMPv3 недопустимо включать в пакет дополнительные октеты сверх описанных здесь.

4.1.11. Варианты запросов

Имеется три вариант сообщений Query:

  1. Запросы общего назначения (General Query) передаются групповыми маршрутизаторами для определения полного состояния приема группового трафика на соседних интерфейсах (т.е, интерфейсах, подключенных к сети, в которую передается запрос). В General Query поля Group Address и Number of Sources (N) равны 0.

  2. Запросы для группы (Group-Specific Query) передаются групповыми маршрутизаторами для определения состояния приема применительно к одному групповому адресу на соседних интерфейсах. В Group-Specific Query поле Group Address содержит интересующий групповой адрес, а поле Number of Sources (N) — 0.

  3. Запросы для группы и источника (Group-and-Source-Specific Query) передаются групповыми маршрутизаторами для определения наличия среди соседних интерфейсов желающего принимать пакеты, направленные по указанному групповому адресу любым из источников в вписке. В запросах Group-and-Source-Specific поле Group Address содержит интересующий адрес, а поля Source Address [i] — список интересующих источников.

4.1.12. Адреса получателей для запросов

Общие запросы в IGMPv3 передаются с использованием IP-адреса получателя 224.0.0.1 (групповой адрес для всех систем. Запросы Group-Specific и Group-and-Source-Specific Queries передаются по интересующему групповому адресу.ы, Однако система должна воспринимать и обрабатывать все сообщения Query, где поле IP Destination Address содержит любой из адресов (индивидуальных и групповых) интерфейса, на котором принят запрос.

4.2. Сообщение Version 3 Membership Report

Сообщения Version 3 Membership Report передаются IP-системами для информирования соседних маршрутизаторов о текущем состоянии приема группового трафика на своих интерфейсах или изменении этого состояния. Формат отчета показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x22  |    Reserved   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |  Number of Group Records (M)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [1]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [2]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      .                               .                               .
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [M]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Каждое поле Group Record имеет показанный ниже формат.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Multicast Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                                                             -+
      .                               .                               .
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                         Auxiliary Data                        .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1. Reserved

Резервное поле устанавливается в 0 при передаче и игнорируется на приемной стороне.

4.2.2. Checksum

Поле контрольной суммы представляет собой 16-битовое дополнение до 1 суммы дополнений до 1 для всего сообщения IGMP (данные пакеты IP). При расчете контрольной суммы само значение поля Checksum предполагается нулевым. На приемной стороне контрольная сумма должна проверяться до начала обработки сообщения.

4.2.3. Number of Group Records (M)

Поле Number of Group Records (M) задает число записей Group Record в данном отчете.

4.2.4. Group Record

Каждая запись Group Record представляет собой блок полей с информацией принадлежности отправителей к одной из multicast-групп на интерфейсе, с которого передается сообщение Report.

4.2.5. Record Type

См. параграф 4.2.12.

4.2.6. Aux Data Len

Поле Aux Data Len указывает размер поля Auxiliary Data данной записи Group Record в 32-битовых словах. Нулевое значение поля говорит об отсутствии дополнительных данных.

4.2.7. Number of Sources (N)

Поле Number of Sources (N) задает число адресов отправителей в данной записи Group Record.

4.2.8. Multicast Address

Поле Multicast Address содержит групповой адрес IP, к которому относится данная запись Group Record.

4.2.9. Source Address [i]

Поле Source Address [i] представляет собой массив из n индивидуальных адресов IP, где n задается полем Number of Sources (N).

4.2.10. Auxiliary Data

При наличии поля Auxiliary Data оно служит для передачи дополнительной информации, относящейся к этой записи Group Record. Описываемый в этом документе протокол IGMPv3 не определяет каких-либо дополнительных данных. Следовательно, рекомендациям IGMPv3 недопустимо включать какие-либо дополнительные данные (т. е., должно устанавливаться Aux Data Len = 0) в передаваемые записи Group Record, а на приемной стороне такие данные должны игнорироваться. Значение и представление полей Auxiliary Data может быть определено в последующих версиях протокола IGMP или его расширений.

4.2.11. Дополнительные данные

Если поле Packet Length в заголовке IP принятого сообщения Report говорит о наличии дополнительных октетов данных после финальной записи Group Record, реализации IGMPv3 должны включать эти октеты в расчет IGMP Checksum, игнорируя их впоследствии. При передаче сообщений Report реализации IGMPv3 недопустимо включать какие-либо данные после финальной записи Group Record.

4.2.12. Типы записей Group Record

Существует множество типов различных записей Group Record, которые могут включаться в сообщения Report.

  • Записи Current-State (текущее состояние) передаются системой в ответ на принятое интерфейсом сообщение Query. Такие записи говорят о текущем состоянии приема на данном интерфейсе применительно к одному групповому адресу. Поле Record Type записи Current-State может принимать одно из двух значений, приведенных ниже.

    Значение

    Имя и описание

    1

    MODE_IS_INCLUDE — указывает, что на интерфейсе для указанного адреса установлен фильтр INCLUDE. Поля Source Address [i] в данной записи Group Record содержат список источников для указанного группового адреса на данном интерфейсе (если список не пуст).

    2

    MODE_IS_EXCLUDE — указывает, что на интерфейсе для указанного адреса установлен фильтр EXCLUDE. Поля Source Address [i] в данной записи Group Record содержат список источников для указанного группового адреса на данном интерфейсе (если список не пуст).

  • Запись Filter-Mode-Change передается системой в тех случаях, когда локальный вызов IPMulticastListen приводит к изменению режима фильтрации (например, с INCLUDE на EXCLUDE или наоборот) в записи состояния интерфейса для конкретного группового адреса. Запись включается в сообщения Report, передаваемые с интерфейса, для которого произошло изменение. Поле Record записей Filter-Mode-Change может принимать одно из двух приведенных ниже значений.

    3

    CHANGE_TO_INCLUDE_MODE — показывает, что на интерфейсе для указанного группового адреса режим фильтрации изменен на INCLUDE. Поля Source Address [i] в данной записи Group Record содержат список источников для указанного группового адреса на данном интерфейсе (если список не пуст).

    4

    CHANGE_TO_EXCLUDE_MODE — показывает, что на интерфейсе для указанного группового адреса режим фильтрации изменен на EXCLUDE. Поля Source Address [i] в данной записи Group Record содержат список источников для указанного группового адреса на данном интерфейсе (если список не пуст).

  • Запись Source-List-Change передается системой, в которой локальный вызов IPMulticastListen приводит к изменению списка источников, не совпадающему со сменой режима фильтрации, в интерфесной записи для конкретного группового адреса. Такая запись включается в сообщение Report, передаваемое интерфейсом, где произошли изменения. Поле Record Type записи Source-List-Change может иметь одно из значений:

5

ALLOW_NEW_SOURCES — показывает, что поля Source Address [i] в данной Group Record содержат список дополнительных источников, которые система хочет принимать при передаче ими пакетов на указанный групповой адрес. Если изменение внесено в список фильтра INCLUDE, адреса добавляются в имеющийся список, если для фильтра задан режим EXCLUDE, добавленные адреса удаляются из списка.

6

BLOCK_OLD_SOURCES — показывает, что поля Source Address [i] в данной Group Record содержат список дополнительных источников, которые система не хочет больше принимать при передаче ими пакетов на указанный групповой адрес. Если изменение внесено в список фильтра INCLUDE, адреса удаляются из имеющегося списка принимаемых источников, если для фильтра задан режим EXCLUDE, адреса добавляются в список исключений.

Если изменение списка источников приводит одновременно к добавлению новых источников и блокировке имеющихся, передаются две записи Group Record для одного группового адреса — одна запись имеет тип ALLOW_NEW_SOURCES, другая — BLOCK_OLD_SOURCES.

Термин State-Change используется для обозначения записи Filter-Mode-Change или Source-List-Change.

Нераспознанные типы записей должны игнорироваться без уведомления.

4.2.13. IP-адреса источников для сообщений Report

Отчеты IGMP передаются с корректным для подсети получателя IP-адресом источника. Адрес отправителя 0.0.0.0 может использоваться системами, которые еще не имеют адреса IP. Отметим, что адрес 0.0.0.0 может одновременно использовать множество систем в ЛВС. Маршрутизаторы должны воспринимать отчеты с адресом отправителя 0.0.0.0.

4.2.14. IP-адреса получателей для сообщений Report

Сообщения Report версии 2 передаются по групповому адресу получателя 224.0.0.22, который прослушивают все поддерживающие IGMPv3 групповые маршрутизаторы. Система, работающая в режиме совместимости с версией 1 или 2, передает отчеты версии 1 или 2 по групповому адресу, указанному полем Group Address в сообщении Report. Кроме того, система должна воспринимать и обрабатывать все сообщения 2 версии 1 и 2, где поле IP Destination Address указывает на любой (индивидуальный или групповой) из интерфейсов системы, получившей сообщение Report.

4.2.15. Нотация для записей Group Record

В оставшейся части этого документа для обозначения содержимого Group Record, относящегося к конкретному групповому адресу используется показанная ниже нотация.

IS_IN ( x ) — тип MODE_IS_INCLUDE, адреса источников x;

IS_EX ( x ) — тип MODE_IS_EXCLUDE, адреса источников x;

TO_IN ( x ) — тип CHANGE_TO_INCLUDE_MODE, адреса источников x;

TO_EX ( x ) — тип CHANGE_TO_EXCLUDE_MODE, адреса источников x;

ALLOW ( x ) — тип ALLOW_NEW_SOURCES, адреса источников x;

BLOCK ( x ) — тип BLOCK_OLD_SOURCES, адреса источников x,

где x может быть:

  • заглавной буквой (например, A) для обозначения множества источников;

  • выражением (например, A+B), где A+B задает объединение множеств A и B, A*B указывает пересечение множеств A и B, A-B означает исключение элементов множества B из множества A.

4.2.16. Размер Membership Report

Если множество записей Group Record в отчете не помещается в размеры одного сообщения Report (определяется MTU в сети, через которую сообщение будет передано), записи Group Record передаются в нескольких сообщениях Report.

Если одна запись Group Record содержит множество адресов источников, которое не помещается в размер записи одного сообщения Report, для типов MODE_IS_EXCLUDE и CHANGE_TO_EXCLUDE_MODE запись делится на множество Group Record, содержащих отдельные подмножества адресов источников, и эти записи передаются в отдельных сообщениях Report. Для типов MODE_IS_EXCLUDE и CHANGE_TO_EXCLUDE_MODE, передается одна запись Group Record, содержащая столько адресов источников, сколько позволяет размер, а оставшиеся адреса просто не передаются; хотя выбор передаваемых адресов может быть произвольным, предпочтительно передавать одно и то же подмножество в каждом последующем отчете, а не выбирать разные подмножества для сообщений.

5. Описание протокола для членов группы

Протокол IGMP является асимметричным и отдельно задает поведение членов групп (хостов и маршрутизаторов, получающих групповой трафик) и групповых маршрутизаторов. В этом параграфе описана та часть IGMPv3, которая относится ко всем членам групп. Отметим, что входящий в группу multicast-маршрутизатор выполняет требования обеих частей IGMPv3, получая сообщения IGMP от себя и своих соседей и отвечая на эти сообщения. Относящаяся к групповым маршрутизаторам часть IGMPv3 описана в разделе 6.

Поддерживающая протокол система выполняет описанные в этом разделе требования на всех своих интерфейсах, принимающих групповой трафик даже при подключении нескольких таких интерфейсов к одной сети.

Для обеспечения взаимодействия с системами, использующими ранние версии IGMP, поддерживается переменная MulticastRouterVersion для каждого интерфейса, на котором принимается групповой трафик. В этом параграфе описано поведение входящих в группы систем на интерфейсах которых задано MulticastRouterVersion = 3. Алгоритм определения MulticastRouterVersion и поведение для других (не 3) версий описано в разделе 7.

Групповой адрес all-systems (224.0.0.1) требует специальной обработки. На всех системах (хосты и маршрутизаторы, включая групповые) получение пакетов, направленных по адресу all-systems из любого источника постоянно разрешено на всех интерфейсах, где разрешается прием группового трафика. Никаких сообщений IGMP, относящихся к групповому адресу all-systems, не передается.

Существует два типа событий, которые вызывают действия протокола IGMPv3 на интерфейсе:

  • изменение состояния приема на интерфейсе, вызванное локальным вызовом IPMulticastListen;

  • прием сообщения Query.

(сообщения IGMP, не являющиеся запросами, игнорируются без уведомления, за исключением случаев, когда их обработка требуется для совместимости с ранними версиями IGMP).

В последующих параграфах описаны действия для каждого из двух упомянутых случаев. В этих описаниях имена таймеров и счетчиков приводятся в квадратных скобках. Принятые по умолчанию значения таймеров и счетчиков приведены в разделе 8.

5.1. Действия при смене состояния интерфейса

Вызов IPMulticastListen может привести к смене состояния приема группового трафика на интерфейсе в соответствии с правилами, приведенными в параграфе 3.2. Каждое такое изменение воздействует на интерфейсную запись для одного группового адреса.

Изменение состояния на интерфейсе заставляет систему незамедлительно передать с этого интерфейса сообщение State-Change Repor. Тип и содержимое Group Record в этом сообщении определяется путем сравнения режима фильтрации и списка источников для затронутого группового адреса до изменения и после его, как показано в таблице ниже. Если до изменения на интерфейсе не было состояния для данного группового адреса (создание интерфейсной записи) или состояние исчезло после изменения (удаление интерфейсной записи), «не существующее» состояние трактуется, как фильтр INCLUDE с пустым списком источников.

Старое состояние

Новое состояние

Переданная запись

INCLUDE (A)

INCLUDE (B)

ALLOW (B-A), BLOCK (A-B)

EXCLUDE (A)

EXCLUDE (B)

ALLOW (A-B), BLOCK (B-A)

INCLUDE (A)

EXCLUDE (B)

TO_EX (B)

EXCLUDE (A)

INCLUDE (B)

TO_IN (B)

Если рассчитанный список источников в ALLOW или BLOCK записи State-Change Record пуст, такая запись не включается в сообщение Report.

На случай пропуска записи State-Change Report одним или множеством групповых маршрутизаторов она повторяется [Robustness Variable] — 1 раз со случайными интервалами из диапазона (0, [Unsolicited Report Interval]).

Если до завершения повторных передач сообщения State-Change Report произошла новая смена состояния, рассчитываются новые изменения и незамедлительно передается новое сообщение State-Change Report.

Расчет содержимого нового отчета для передачи показан ниже. Как и для первого сообщения сравнивается состояние интерфейса для затронутой группы до и после позднейшего изменений. Записи отчета, показывающие различия, строятся в соответствии с приведенной выше таблицей. Однако эти записи не передаются в сообщении непосредственно, а объединяются с содержимым ожидающего отчета для создания нового сообщения State-Change. Правила слияния описаны ниже.

Передача слитого сообщения State-Change Report прерывает повтор передачи предшествующих сообщений State-Change Report для того же группового адреса и начинает первую из [Robustness Variable] передач новых сообщений State-Change Report.

При каждом включении источника в разные отчеты, созданные как описано выше, для этого источника нужно поддерживать состояние повтора передачи пока хостом не будет передано [Robustness Variable] сообщений State-Change. Это делается для того, чтобы последовательные смены состояний не нарушали устойчивость протокола.

Если вызвавшая новый отчет смена состояния интерфейса является изменением режима фильтрации, следующие [Robustness Variable] сообщений State-Change Report будут включать запись Filter-Mode-Change. Это применимо даже для тех случаев, когда в течение этого периода произошли изменения списка источников. Хост поддерживает состояние повтора для группы, пока не будут переданы [Robustness Variable] сообщений State-Change. Когда было передано [Robustness Variable] сообщений State-Change с записями Filter-Mode-Change после смены режима фильтрации и смена списка источников для интерфейса вызывает дополнительные отчеты, следующее сообщение State-Change будет включать записи Source-List-Change.

При каждой передаче State-Change Report содержимое сообщения определяется, как описано ниже. Если в отчет следует включать запись Filter-Mode-Change, тогда при режиме фильтрации на интерфейсе INCLUDE в сообщение включается запись TO_IN, в остальных случаях — TO_EX. Если же в отчет следует включать записи Source-List-Change, следует включать запись ALLOW и BLOCK. Содержимое упомянутых записей показано в таблице.

Запись

Включенные источники

TO_IN

Все из текущего состояния интерфейса, для которых должна выполняться пересылка.

TO_EX

Все из текущего состояния интерфейса, которые должны блокироваться.

ALLOW

Все с состоянием повторной передачи, что должно пересылаться.

BLOCK

Все с состоянием повторной передачи, что должно блокироваться.

Если рассчитанный список источников для записи ALLOW или BLOCK пуст, такая запись не включается в сообщение State-Change.

Примечание. При передача первого сообщения State-Change отсутствующий отчет для слияния может рассматриваться, как отчет об изменении состояния с пустыми записями ALLOW и BLOCK (ни для одного источника нет состояния повтора передачи).

5.2. Действия при получении запроса

Получив сообщение Query, система не реагирует на него незамедлительно. Отклик задерживается не некоторое случайное время, ограниченное значением Max Resp Time, которое определяется из Max Resp Code в полученном запросе. Система может получать на разных интерфейсах разные запросы (например, General Query, Group-Specific Query, Group-and-Source-Specific Query), каждый из которых может потребовать своей задержки с откликом.

Перед планированием отклика на сообщение Query система должна сначала принять во внимание ожидающие отклики — во многих случаях планируемый отклик можно будет объединить с ожидающим. Следовательно, система должна поддерживать следующие параметры состояния:

  • таймеры для интерфейсов при планировании откликов на General Query;

  • таймеры для групп и интерфейсов при планировании откликов на запросы Group-Specific и Group-and-Source-Specific;

  • списки источников для групп и интерфейсов, включаемые в отклики на Group-and-Source-Specific Query.

При получении нового сообщения Query с опцией Router-Alert на интерфейсе и система имеет состояние для оповещения, задержка с откликом выбирается случайным образом из диапазона (0, [Max Resp Time]), где значение Max Resp Time выводится из Max Resp Code в принятом сообщении Query. После этого используются приведенные ниже правила для определения планирования и типа сообщения Report. Правила применяются до обнаружения первого соответствия.

  1. При наличии ожидающего отклика на предшествующий запрос General, запланированного раньше выбранной задержки, планировать дополнительный отлик не требуется.

  2. Если получен запрос General, используется таймер интерфейса для планирования отклика на него по истечении заданного времени. Все ожидающие предшествующие отклики на General Query отбрасываются.

  3. Если получен запрос Group-Specific или Group-and-Source-Specific и нет ожидающих откликов на предшествующие запросы для данной группы, используется таймер группы для планирования отклика. Если получен запрос Group-and-Source-Specific, список источников из него записывается для использования при генерации отклика.

  4. Если имеется ожидающий отклик на предшествующий запрос для данной группы и новый запрос является Group-Specific Query или записанный список связанных с группой источников пуст, список источников для группы очищается и планируется один отклик с использованием таймера группы. Новый отклик планируется для передачи по истечении меньшего из двух сроков — оставшееся время ожидания и выбранная задержка.

  5. Если получен запрос Group-and-Source-Specific и для этой группы имеется ожидающий отклик с непустым списком источников, список источников для данной группы дополняется списком из полученного запроса и планируется один отклик с использованием таймера группы. Новый отклик планируется для передачи по истечении меньшего из двух сроков — оставшееся время ожидания и выбранная задержка.

Когда отсчет таймера для ожидающего отклика завершается, система передает через соответствующий интерфейс одно или множество сообщений Report содержащих одну или множество записей Current-State Record (см. параграф 4.2.12), как описано ниже:

  1. Если отсчет завершился для таймера интерфейса (т. е., в ожидании находится отклик на General Query), передается одна запись Current-State Record для каждого группового адреса, по отношению к которому у данного интерфейса имеется состояние восприятия, как описано в параграфе 3.2. Current-State Record передает групповой адрес и связанный с ним режим фильтрации (MODE_IS_INCLUDE или MODE_IS_EXCLUDE), а также список источников. Записи Current-State Record помещаются в отдельные сообщения Report (насколько позволяет размер).

  2. Использование этого наивного алгоритма может приводить к значительным всплескам трафика в тех случаях, когда система входит в большое число групп. Вместо использования одного интерфейсного таймера реализациям рекомендуется распределять передачу таких сообщений Report в интервале (0, [Max Resp Time]). Отметим, что такие реализации должны предотвращать возникновение проблемы ack-implosion (взрыв подтверждений) (т. е., недопустима передача сообщений Report сразу же при получении General Query).

    Если завершился отсчет для таймера группы и список сохраненных источников для группы пуст (т. е., имеется ожидающий отклик на Group-Specific Query), тогда (и только тогда) при наличии на интерфейсе состояния приема для данного группового адреса передается одна запись Current-State Record для этого адреса. Запись Current-State содержит групповой адрес, связанный с ним режим фильтрации (MODE_IS_INCLUDE или MODE_IS_EXCLUDE) и список источников.

  3. IЕсли завершился отсчет для таймера группы и список сохраненных источников для группы не пуст (т. е., имеется ожидающий отклик на Group-and-Source-Specific Query), тогда (и только тогда) при наличии на интерфейсе состояния приема для данного группового адреса содержимое записи Current-State Record в отклике определяется из состояния интерфейса и ожидающего отклика, как показано в таблице ниже:

Набор источников в

состоянии интерфейса

записи ожидания отклика

записи текущего состояния

INCLUDE (A)

B

IS_IN (A*B)

EXCLUDE (A)

B

IS_IN (B-A)

Если в полученной записи Current-State Record набор адресов отправителей будет пустым, отклик не передается.

В заключении, после генерации всех требуемых сообщений Report списки источников, связанные с группами, для которых передавались отчеты, очищаются.

6. Описание протокола для групповых маршрутизаторов

Целью IGMP является обеспечение каждому групповому маршрутизатору возможности узнать для всех подключенных непосредственно сетей групповые адреса, представляющие интерес для находящихся в этих сетях систем. IGMP версии 3 добавляет для групповых маршрутизаторов возможность узнать какие источники интересуют соседние системы для пакетов, направленных по любому конкретному групповому адресу. Собранная IGMP информация предоставляется используемому маршрутизатором протоколу групповой маршрутизации для того, чтобы групповые пакеты были доставлены во все сети, где есть заинтересованные получатели.

В этом разделе описана часть протокола IGMPv3, выполняемая групповыми маршрутизаторами. Эти маршрутизаторы сами могут быть членами multicast-групп и, следовательно, будут выполнять связанную с членами групп часть IGMPv3, описанную в разделе 5.

Групповой маршрутизатор исполняет описанный в этом разделе протокол для каждой из подключенных непосредственно к нему сетей. Если групповой маршрутизатор имеет несколько интерфейсов в одну сеть, достаточно исполнять этот протокол на одном из таких интерфейсов. На каждом интерфейсе, где используется протокол, маршрутизатор должен разрешить восприятие пакетов, направленных по групповому адресу 224.0.0.22, из всех источников (и должен исполнять групповую часть IGMPv3 для данного адреса на этом интерфейсе).

Групповому маршрутизатору нужно знать лишь, что хотя бы одна система в подключенной сети заинтересована в пакетах, направленных по конкретному групповому адресу из конкретного источника; ему не требуется отслеживать интересы каждой из соседних систем (см. дополнительное обсуждение в Приложении A.2, п. 1).

IGMPv3 обеспечивает совместимость с более ранними версиями протокола IGMP. Для этого групповые маршрутизаторы IGMPv3 должны также реализовать версии протокола 1 и 2 (см. раздел 7).

6.1. Условия для запросов IGMP

Групповые маршрутизаторы периодически отправляют запросы General Query для получения данных о принадлежности к группам из подключенных сетей. Эти запросы используются для создания и обновления состояния принадлежности к группам систем в подключенных сетях. Системы отвечают на такие запросы сообщениями со своим статусом присутствия в группах (и желаемыми наборами источников) в записях Current-State Group Record сообщений IGMPv3 Membership Report.

Как член multicast-группы, система может выражать свою заинтересованность в получении или отказе от получения трафика из конкретных источников. При изменении желаемого состояния восприятия в системе, она сообщает об этих изменениях, используя записи Filter-Mode-Change и/или Source-List-Change. Такие записи указывают явное изменение состояния для группы в системе в части списка источников или режима фильтрации. Когда участие в группе прерывается для системы или получение трафика от конкретного источника становится нежелательным, групповой маршрутизатор должен запросить других участников группы или прослушивающих тот же источник прежде, чем удалить группу (или источник) и отсечь соответствующий трафик.

Для обеспечения всем системам в сети возможности отвечать на изменения принадлежности к группам групповые маршрутизаторы передают специальные запросы. Group-Specific Query передается для того, чтобы убедиться в отсутствии систем, желающих принимать конкретную группу, или перестроить состояние восприятия для конкретной группы. Запросы Group-Specific передаются в тех случаях, когда маршрутизатор получает запись State-Change, указывающую выход системы из группы.

Запросы Group-and-Source Specific служат для проверки отсутствия в сети систем, желающих получать трафик из указанного набора источников. Group-and-Source Specific указывают источники для конкретной группы, относительно которых был запрошен отказ от пересылки. Такие запросы передаются групповыми маршрутизаторами для того, чтобы определить наличие систем, желающих получать пакеты по указанному групповому адресу из заданного списка источников. Запросы Group-and-Source Specific передаются только в ответ на получение записей State-Change и никогда не передаются в ответ на записи Current-State. Более подробно запросы описаны в параграфе 4.1.11.

6.2. Состояние IGMP, поддерживаемое групповыми маршрутизаторами

Групповые маршрутизаторы, поддерживающие IGMPv3 сохраняют состояния по группам и подключенным сетям. Состояние для группы включает режим фильтрации, список источников и разные таймеры. Для каждой подключенной сети, где используется IGMP, групповой маршрутизатор сохраняет желаемое состояние восприятия, которое представляет собой набор записей виде:

(multicast address, group timer, filter-mode, (source records))

Каждая запись для источника (source record) имеет форму:

(source address, source timer)

Если желательны все источники в данной группе, сохраняется пустая запись источников с режимом фильтрации EXCLUDE. Это показывает, что хосты данной сети желают пересылки всех источников для данной группы. В IGMPv3 это служит эквивалентов включения в группу IGMPv1 или IGMPv2.

6.2.1. Определение Router Filter-Mode

Для снижения числа внутренних состояний маршрутизаторы IGMPv3 хранят режимы фильтрации по группам и подключенным сетям. Эти режимы используются для сжатия общего желаемого состояния приема группы до минимального набора, который удовлетворит все входящие в группу системы. Режим фильтрации может меняться в ответ на получение отдельных типов записей от групп или по событиям, связанным с таймерами. В последующих параграфах используется термин router filter-mode для обозначения режима фильтрации применительно к конкретной группе. В параграфе 6.4 описаны изменения режима фильтрации при получении записей от групп.

Концептуально при получении записи от группы режим фильтрации для данной группы меняется так, чтобы включались все запрошенные источники с применением минимального числа состояний. Как правило, при получении от группы записи с режимом фильтрации EXCLUDE маршрутизатор будет использовать для данной группы фильтр EXCLUDE.

Когда в маршрутизаторе для группы установлен фильтр EXCLUDE, запись со списком источников содержит два типа источников. Первый набор включает источники, которые конфликтуют с желаемым состоянием восприятия — для этого типа должна обеспечиваться пересылка на том или ином маршрутизаторе сети. Второй набор включает источники, для которых хосты запросили отказ от пересылки. В Приложении A описаны причины хранения этого набора при фильтрации в режиме EXCLUDE.

Когда в маршрутизаторе для группы установлен фильтр INCLUDE, запись со списком источников представляет собой список источников, которые группа желает принимать. Это общий набор желаемых источников для данной группы. Для каждого источника в списке должна обеспечиваться пересылка на том или ином маршрутизаторе сети.

Поскольку переданная групповая запись с режимом фильтрации EXCLUDE будет вынуждать маршрутизатор сменить свой режим фильтрации на EXCLUDE, требуется механизм для возврата маршрутизаторов в режим INCLUDE. Если все системы из группы с режимом EXCLUDE прекратили присылать отчеты, на маршрутизаторе желательно вернуть для этой группы режим INCLUDE. Переход происходит по групповому таймеру, как описано в параграфе 6.5.

6.2.2. Определение групповых таймеров

Групповой таймер используется только для групп в режиме EXCLUDE и представляет время, когда режим фильтрации (filter-mode) для данной группы будет заменен на INCLUDE. Групповые таймеры организуются по группам и подключенным сетям. Групповые таймеры обновляются в соответствии с получаемыми групповыми записями.

Отсчет группового таймера завершается, когда в маршрутизаторе для группы установлен фильтр EXCLUDE и в подключенной сети не остается больше получателей с режимом EXCLUDE. В этот момент маршрутизатор переходит в режим фильтрации INCLUDE. Описание действий при таком переходе приведено в параграфе 6.5.

В таблице ниже показаны роли группового таймера. В параграфе 6.4 подробно описана установка группового таймера по типам получаемых групповых записей.

Режим фильтрации

Значение таймера

Действия и описание

INCLUDE

Timer >= 0

Все участники группы в режиме INCLUDE.

EXCLUDE

Timer > 0

По крайней мере один участник в режиме EXCLUDE.

EXCLUDE

Timer == 0

В группе больше нет участников. По завершении отсчета таймеров на источниках запись Group Record удаляется.

6.2.3. Определение таймеров источника

Таймеры источников организуются по записям для источников и декрементируются до достижения нулевого значения. Обновляются эти таймеры в соответствии с типом и режимом фильтрации получаемых групповых записей. Таймер (для конкретной группы) всегда обновляется при наличии данного источника в полученной записи для этой группы. В параграфе 6.4 описана организация таймера источника по типам групповых записей.

Запись для источника с запущенным таймером и режимом фильтрации для группы INCLUDE говорит о наличии одной или множества систем (с режимом фильтрации INCLUDE), которые желают принимать этот источник. Если для группы с режимом фильтрации INCLUDE отсчет таймера источника завершается, маршрутизатор считает, что трафик от этого источника больше не нужен в подключенной сети и удаляет соответствующую запись для источника.

Таймеры источников трактуются иначе в тех случаях, когда на маршрутизаторе для группы используется режим фильтрации EXCLUDE. Если для записи источника имеется запущенный таймер и на маршрутизаторе для группы установлен режим фильтрации EXCLUDE, это означает, что источник является желанным по крайней мере для одной системы. Следовательно, маршрутизатору нужно пересылать пакеты от этого источника в сеть. В Приложении A описаны причины сохранения состояния для источников, по отношению к которым была запрошена пересылка, несмотря на режим EXCLUDE.

Если отсчет таймера завершается с режимом фильтрации для группы EXCLUDE, маршрутизатор информирует протокол маршрутизации об отсутствии в сети получателей для данного источника.

При режиме фильтрации EXCLUDE для группы записи источников удаляются только по завершения отсчета группового таймера. В параграфе 6.описаны действия, которые следует выполнять в зависимости от значения таймера для источника.

6.3. Правила пересылки IGMPv3

Когда групповой маршрутизатор получает от источника дейтаграммы, направленные в конкретную группу, этот маршрутизатор принимает решения о пересылке дейтаграмм в подключенные к нему сети. Ответственность за принятие такого решения лежит на используемом протоколе групповой маршрутизации и следует ему использовать данные IGMPv3 для того, чтобы все источники/группы, желаемые в той или иной подсети, пересылались в данную подсеть. Например, если для группы G задан режим фильтрации EXCLUDE, маршрутизатор может продолжать пересылку исключенных пакетов в транзитную подсеть.

Приведенная ниже таблица описывает предложения по пересылке, направляемые IGMP протоколу маршрутизации для трафика от источника, направленного в ту или иную группу. Указаны также действия, предпринимаемые по завершению отсчета таймера источника на основе режима фильтрации для группы.

Режим фильтрации

Значение таймера

Действия

INCLUDE

Timer > 0

Предложить пересылку трафика от источника.

INCLUDE

Timer = 0

Предложить прекратить пересылку трафика от источника и удалить его запись. Если в группе не остается записей для источников, удалить запись группы.

INCLUDE

Нет источников

Предложить не пересылать трафик.

EXCLUDE

Timer > 0

Предложить пересылку трафика от источника.

EXCLUDE

Timer == 0

Предложить не пересылать трафик от источника (не удалять запись).

EXCLUDE

Нет источников

Предложить пересылку трафика от источника.

6.4. Действия при получении сообщений

6.4.1. Получение записей Current-State

При получении записей Current-State маршрутизатор обновляет свои таймеры для группы и источника. В некоторых случаях получение групповой записи будет вынуждать маршрутизатор изменить режим фильтрации для данной группы. В приведенной ниже таблице показаны действия по отношению к состоянию и таймера, которые может вызывать в маршрутизаторах получение записей Current-State.

Для описания обновлений таймера источника используются специальные обозначения — запись вида (A, B) будет представлять общее число источников для отдельной группы, где

A — множество записей источников, для которых значения таймеров > 0 (хоты бы 1 хост запросил пересылку);

B — множество записей источников, для которых значения таймеров = 0 (источники, для которых IGMP будет предлагать отказ от пересылки).

Отметим, что два множества записей используется только в режиме фильтрации для группы EXCLUDE на маршрутизаторе. Если на маршрутизаторе установлен для группы режим фильтрации INCLUDE, используется одно множество для описания источников, по отношению к которым запрошена пересылка (например, simply (A)).

В последующих таблицах для нескольких переменных используются сокращенные обозначения (они подробно описаны в разделе 8). Переменная GMI7 указывает интервал, по истечении которого членство в группе прекращается. Переменная LMQT8 указывает общее время, прошедшее после Last Member Query Count повторов. Значение LMQT представляет «задержку выпуска» или разницу между моментом передачи информации об изменении членства в группе и изменением сведений, предоставляемых протоколу маршрутизации.

В колонке «Действия» таблиц состояний маршрутизатора используются обозначения вида A=J, которые указывают, что множество записей источников A должно установить для своих таймеров значение J. Действие Delete A указывает удаление множества записей источников A. Group Timer=J означает, что в Group Timer для группы следует установить значение J.

Состояние маршрутизатора

Полученный отчет

Новое состояние

Действия

INCLUDE (A)

IS_IN (B)

INCLUDE (A+B)

(B)=GMI

INCLUDE (A)

IS_EX (B)

EXCLUDE (A*B,B-A)

(B-A)=0
Delete (A-B)
Group Timer=GMI

EXCLUDE (X,Y)

IS_IN (A)

EXCLUDE (X+A,Y-A)

(A)=GMI

EXCLUDE (X,Y)

IS_EX (A)

EXCLUDE (A-Y,Y*A)

(A-X-Y)=GMI
Delete (X-A)
Delete (Y-A)
Group Timer=GMI

6.4.2. Получение записей Filter-Mode-Change и Source-List-Change

Когда в системе происходит глобальное изменение состояния группы, данная система передает для этой группы запись Source-List-Change или Filter-Mode-Change. Как и в случае с записями Current-State, маршрутизаторы должны реагировать на получение такой информации и могут изменять свое состояние в соответствии с новым желаемым состоянием принадлежности к группам в сети.

Routers must query sources that are requested to be no longer forwarded to a group. Когда маршрутизатор отправляет или получает запрос для конкретного набора источников, он снижает значения таймеров для этих источников до значения Last Member Query Time (в секундах). Если в ответ на запросы получены групповые записи, которые показывают заинтересованность в получении трафика из соответствующих источников, таймеры для этих источников обновляются.

Аналогично, при запросе маршрутизатора для конкретной группы, он снижает значение таймера для этой группы до Last Member Query Time секунд. Если в заданном интервале получена какая-либо групповая запись с режимом EXCLUDE, таймер для соответствующей группы обновляется и протоколу маршрутизации передается предложение сохранять пересылку для данной группы без прерывания.

В течение периода запроса (т. е., Last Member Query Time секунд) компонента IGMP в маршрутизаторе продолжает предлагать протоколу маршрутизации пересылать трафик, связанный с группами и источниками, указанными в запросе. Если в течение Last Member Query Time секунд не будет получена запись с выражением интереса для указанных в запросе групп или источников, маршрутизатор может «отсечь» группу или источники от сети.

В приведенной ниже таблице указаны изменения в состояниях групп и действия при получении записей Filter-Mode-Change или Source-List-Change. Указаны также запросы, передаваемые при получении тех или иных отчетов.

При описании передаваемых запросов используется обозначение Q(G) для запроса Group-Specific применительно к группе G, Q(G,A) для запроса Group-and-Source Specific применительно к группе G и списку источников A. Если в результате действия (например, A*B) список источников становится пустым, запроса после операции не передается.

Для обеспечения отказоустойчивости протокола запросы, передаваемые перечисленными в таблице действиями, требуется передавать [Last Member Query Count] раз в течение каждого интервала [Last Member Query Interval].

Если в момент планирования нового запроса еще имеются ожидающие повторной передачи запросы для той же группы, новый запрос может быть объединен с имеющимся. Кроме того, получение отчета хоста для группы с ожидающими запросами может оказывать влияние на содержимое этих запросов. Построение и поддержка состояний очередей ожидания описаны в параграфе 6.6.3.

Состояние маршрутизатора

Полученный отчет

Новое состояние

Действия

INCLUDE (A)

ALLOW (B)

INCLUDE (A+B)

(B)=GMI

INCLUDE (A)

BLOCK (B)

INCLUDE (A)

Send Q(G,A*B)

INCLUDE (A)

TO_EX (B)

EXCLUDE (A*B,B-A)

(B-A)=0
Delete (A-B)
Send Q(G,A*B)
Group Timer=GMI

INCLUDE (A)

TO_IN (B

INCLUDE (A+B)

(B)=GMI
Send Q(G,A-B)

EXCLUDE (X,Y)

ALLOW (A)

EXCLUDE (X+A,Y-A)

(A)=GMI

EXCLUDE (X,Y)

BLOCK (A)

EXCLUDE (X+(A-Y),Y)

(A-X-Y)=Group Timer
Send Q(G,A-Y)

EXCLUDE (X,Y)

TO_EX (A)

EXCLUDE (A-Y,Y*A)

(A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI

EXCLUDE (X,Y)

TO_IN (A)

EXCLUDE (X+A,Y-A)

(A)=GMI
Send Q(G,X-A)
Send Q(G)

6.5. Переключение режима фильтрации

Групповой таймер служит механизмом переключения из режима фильтрации на маршрутизаторе из EXCLUDE в INCLUDE.

Когда отсчет группового таймера завершается в режиме фильтрации EXCLUDE, маршрутизатор считает, что в подключенных сетях не осталось систем с режимом фильтрации EXCLUDE. Когда на маршрутизаторе установлен для группы режим фильтрации EXCLUDE и отсчет группового таймера завершается, маршрутизатор переключает режим фильтрации для группы на INCLUDE.

Маршрутизатор использует записи для источников с запущенными таймерами источников в качестве своего состояния для переключения в режим фильтрации INCLUDE. Если есть хотя бы одна запись для источника со значением таймера источника больше 0 (т. е., с запрашиваемой пересылкой), маршрутизатор переключается в режим фильтрации INCLUDE, используя такие записи для источников. Записи для источников с нулевым значением таймера (из предыдущего режима EXCLUDE) удаляются.

Например, если состояние маршрутизатора для группы EXCLUDE(X,Y) и для этой группы завершается отсчет таймера, маршрутизатор переключается в режим фильтрации INCLUDE с состоянием INCLUDE(X).

6.6. Действия при получении запросов

6.6.1. Обновление таймеров

Когда маршрутизатор передает или принимает запрос со сброшенным флагом Suppress Router-Side Processing, он должен обновить свои таймеры в соответствии с корректными значениями тайм-аутов для запрашиваемой группы или источников. В таблице показаны действия при передаче или приеме запроса Group-Specific или Group-and-Source Specific Query со сброшенным флагом Suppress Router-Side Processing.

Запрос

Действие

Q(G,A)

Значение Source Timer для источников A снижается до LMQT.

Q(G)

Значение Group Timer снижается до LMQT.

При получении или передаче маршрутизатором запросов с установленным флагом Suppress Router-Side Processing этот маршрутизатор не обновляет значения своих таймеров.

6.6.2. Выбор запрашивающего

IGMPv3 выбирает одного запрашивающего на подсеть, используя такой же механизм выбора, как IGMPv2, а именно — адрес IP. Когда маршрутизатор получает запрос с меньшим адресом IP, он устанавливает для таймера Other-Querier-Present значение Other Querier Present Interval и перестает отправлять запросы в сеть, если ранее уже был выбран запрашивающий. По завершении отсчета таймера Other-Querier Present следует возобновить передачу General Query.

Если маршрутизатор получает более старую версию запроса, он должен использовать для этой сети более старую версию IGMP. Рассмотрение вопросов совместимости разных версий IGMP приведено в разделе 7.

6.6.3. Создание и отправка запросов

6.6.3.1. Создание и отправка запросов для группы

Когда в таблице указано действие Send Q(G), значение для таймера группы должно быть уменьшено до LMQT. В этом случае маршрутизатор должен незамедлительно отправить специфичный для группы запрос и запланировать [Last Member Query Count — 1] его повторов за каждый [Last Member Query Interval] в течение [Last Member Query Time].

При передаче специфичного для группы запроса, если значение таймера для группы больше LMQT, бит Suppress Router-Side Processing устанавливается в каждом сообщении.

6.6.3.2. Создание и отправка запросов для группы и источника

Когда запрашивающий встречает действие Send Q(G,X) в таблице 6.4.2, должны выполняться приведенные ниже операции для каждого источника X группы G со значением таймера больше LMQT:

  • установить число повторов для каждого источника [Last Member Query Count];

  • снизить значение таймера до LMQT.

Маршрутизатор должен незамедлительно передать специфичный для группы и источника запрос, а также запланировать передачу [Last Member Query Count — 1] повторов за каждый [Last Member Query Interval] в течение [Last Member Query Time]. Содержимое этих запросов рассчитывается, как показано ниже.

При создании специфичного для группы и источника запроса для группы G, передаются два отдельных сообщения с запросами. В первом сообщении устанавливается бит Suppress Router-Side Processing и содержатся все источники с состоянием повтора и таймерами больше LMQT. Во втором сообщении бит Suppress Router-Side Processing сброшен и содержатся все источники с состоянием повтора и таймерами не более LMQT. Если в любом из этих двух сообщений не содержится ни одного источника, передача такого сообщения не происходит.

Примечание. Если передача специфичного для группы запроса запланирована на одно время с передачей специфичного для группы и источников запроса для той же группы, передача специфичного для группы и источников сообщения с установленным битом Suppress Router-Side Processing может быть отменена.

7. Взаимодействие с ранними версиями IGMP

Хосты и маршрутизаторы IGMP версии 3 могут взаимодействовать с хостами и маршрутизаторами, еще не обновленными до IGMPv3. Такая совместимость обеспечивается действиями хостов и маршрутизаторов с учетом версий IGMP, используемых на хостах и маршрутизаторах в сети.

7.1. Различия версий запросов

Версия IGMP для сообщений Membership Query определяется следующим образом:

IGMPv1 Query: размер 8 октетов и поле Max Resp Code имеет значение 0
IGMPv2 Query: размер 8 октетов и поле Max Resp Code имеет ненулевое значение
IGMPv3 Query: размер не менее 12 октетов

Запросу, не соответствующие ни одному из приведенных выше вариантов (например, с размером 10 октетов), должны отбрасываться без уведомления.

7.2. Поведение членов группы

7.2.1. При наличии запросов прежних версий

Для совместимости с маршрутизаторами старых версий хосты IGMPv3 должны работать в режимах совместимости с версиями 1 и 2. Хосты IGMPv3 должны сохранять поинтерфейсное состояние для режима совместимости в каждой из подключенных сетей. Режим совместимости на хосте определяется из переменной Host Compatibility Mode, которая может принимать три значения — IGMPv1, IGMPv2 или IGMPv3. Значения переменной хранятся для отдельно для каждого интерфейса и зависят от версии сообщений General Query, принимаемых этим интерфейсом, а также таймеров Older Version Querier Present для этого интерфейса.

Для беспроблемного переключения с одной версии IGMP на другую хосты сохраняют оба таймера IGMPv1 Querier Present и IGMPv2 Querier Present для каждого интерфейса. Для таймера IGMPv1 Querier Present устанавливается значение Older Version Querier Present Timeout (в секундах) при получении запроса IGMPv1 Membership Query. Для таймера IGMPv2 Querier Present устанавливается значение Older Version Querier Present Timeout (в секундах) при получении запроса IGMPv2 General Query.

Режим совместимости Host Compatibility Mode на интерфейсе меняется при получении запроса более старой версии (по сравнению с текущим режимом) или по завершению отсчета таймера. При завершении отсчета IGMPv1 Querier Present хост переключается в режим совместимости с IGMPv2, если у него запущен таймер IGMPv2 Querier Present. Если работающего таймера IGMPv2 Querier Present нет, хост переключается в режим совместимости IGMPv3. При завершении отсчета таймера IGMPv2 Querier Present хост переключается в режим совместимости IGMPv3.

Значение переменной Host Compatibility Mode определяется наиболее старой версией запроса General, принятой за последние Older Version Querier Present Timeout секунд. Установка Host Compatibility Mode определяется таблицей.

Режим совместимости хоста

Состояние таймера

IGMPv3 (по умолчанию)

Таймеры IGMPv2 Querier Present и IGMPv1 Querier Present не запущены

IGMPv2

Таймер IGMPv2 Querier Present запущен, а IGMPv1 Querier Present не запущен

IGMPv1

IGMPv1 Querier Present запущен

Если хост получает запрос, требующий обновления таймеров Querier Present и соответствующей смены режима совместимости, менять режим следует незамедлительно.

В режиме совместимости IGMPv3 хост использует на данном интерфейсе протокол IGMPv3. В режиме совместимости IGMPv2 хост использует на интерфейсе только протокол IGMPv2. В режиме совместимости IGMPv1 хост использует на интерфейсе только протокол IGMPv1.

Маршрутизатор IGMPv1 будет передавать сообщения General Query с Max Resp Code = 0. Это значение должно интерпретироваться, как 100 (10 секунд).

Маршрутизатор IGMPv2 будет передавать сообщения General Query с желаемым значением Max Resp Code (диапазон значений Max Resp Time является линейным, а описанный в параграфе 4.1.1 экспоненциальный алгоритм не применяется).

При смене хостом режима совместимости он сбрасывает все ожидающие отклики и таймеры повтора передачи.

7.2.2. При наличии членов групп со старой версией

Хост IGMPv3 может быть размещен в сети, где имеются хосты, еще не обновленные до IGMPv3. Хост может позволить замену записи IGMPv3 Membership Record на Version 1 Membership Report или Version 2 Membership Report.

7.3. Поведение группового маршрутизатора

7.3.1. Присутствие запрашивающих со старой версией

Маршрутизаторы IGMPv3 могут размещаться в сетях, где имеется хотя бы один маршрутизатор, не обновленный до IGMPv3. В этом случае применяются следующие правила:

  • Если в маршрутизаторах присутствуют более старые версии IGMP, запрашивающий должен использовать меньшую из версий IGMP, представленных в сети. Это требование должно быть реализовано на административном уровне — маршрутизаторы, желающие быть совместимыми с IGMPv1 и IGMPv2, должны иметь конфигурационную опцию для работы в режиме совместимости IGMPv1 или IGMPv2. При работе в режиме IGMPv1 маршрутизаторы должны передавать сообщения Periodic Query с Max Resp Code = 0, усеченные по полю Group Address (т. е., размером 8 байтов), а также должны игнорировать сообщения Leave Group. Им также следует выдавать предупреждения при получении запросов IGMPv2 или IGMPv3, но частота генерации таких предупреждений должна быть ограничена. При работе в режиме IGMPv2 маршрутизаторы должны передавать сообщения Periodic Query, усеченные по полю Group Address (т. е., размером 8 байтов) и им также следует генерировать предупреждения при получении запросов IGMPv3 (частота таких предупреждений должна быть ограничена). Они также должны заполнять поля Max Resp Time с Max Resp Code (т. е., описанный в параграфе 4.1.1 экспоненциальный алгоритм не используется).

  • Если маршрутизатор не настроен явно на использование IGMPv1 или IGMPv2 и получает сообщение IGMPv1 Query или IGMPv2 General Query, ему следует зафиксировать предупреждение. Частота таких предупреждений должна быть ограничена.

7.3.2. Присутствие членов групп со старой версией

Маршрутизаторы IGMPv3 могут размещаться в сетях с хостами, еще не обновленными до IGMPv3. Для обеспечения совместимости со старыми версиями маршрутизаторы IGMPv3 должны работать в режиме совместимости с версией 1 или 2. Маршрутизаторы IGMPv3 сохраняют режимы совместимости по группам. Режим для группы определяется из переменной Group Compatibility Mode, которая может принимать одно из трех значений: IGMPv1, IGMPv2, IGMPv3. Переменная хранится для групповой записи и зависит от версии сообщения Membership Report, принятого для данной группы, и таймера Older Version Host Present для этой группы.

Для беспроблемного переключения между версиями IGMP маршрутизатор поддерживает для каждой групповой записи таймеры IGMPv1 Host Present и IGMPv2 Host Present. Для таймера IGMPv1 Host Present устанавливается значение Older Version Host Present Timeout (в секундах) при получении IGMPv1 Membership Report. Для таймера IGMPv2 Host Present устанавливается значение Older Version Host Present Timeout (в секундах) при получении IGMPv2 Membership Report.

Режим Group Compatibility Mode для групповой записи меняется при получении отчета более старой (по сравнению с текущим режимом) версии или по завершению отсчета таймеров. Когда завершается отсчет таймера IGMPv1 Host Present, маршрутизатор меняет режим Group Compatibility на IGMPv2, если запущен таймер IGMPv2 Host Present. Если запущенного таймера IGMPv2 Host Present нет, маршрутизатор меняет режим Group Compatibility на IGMPv3. При завершении отсчета таймера IGMPv2 Host Present и отсутствии запущенного таймера IGMPv1 Host Present маршрутизатор меняет режим Group Compatibility на IGMPv3. Отметим, что при возврате для группы режима IGMPv3 требуется некоторое время на восстановление данных состояния, связанного с источниками. Специфичная для источников информация будет определяться следующим запросом General Query, но источники, которые следует блокировать, не будут блокироваться в течение интервала [Group Membership Interval] после него.

Значение переменной Group Compatibility Mode определяется версией наиболее старого отчета из числа принятых за последний интервал Older Version Host Present Timeout (в секундах). Выбор значения Group Compatibility Mode показан в таблице.

Режим совместимости группы

Состояние таймера

IGMPv3 (по умолчанию)

Таймеры IGMPv2 Host Present и IGMPv1 Host Present не запущены

IGMPv2

Таймер IGMPv2 Host Present запущен, а IGMPv1 Host Present не запущен

IGMPv1

Таймер IGMPv1 Host Present запущен

Если маршрутизатор получает отчет, требующий обновить таймеры Host Present и, соответственно, поменять режим совместимости, ему следует переключить режим совместимости незамедлительно.

В режиме совместимости для группы (Group Compatibility Mode) IGMPv3 маршрутизатор использует для данной группы протокол IGMPv3.

В режиме совместимости IGMPv2 маршрутизатор транслирует сообщения IGMPv2 в эквиваленты IGMPv3:

Сообщение IGMPv2

Эквивалент IGMPv3

Report

IS_EX( {} )

Leave

TO_IN( {} )

Сообщения IGMPv3 BLOCK игнорируются, как и списки источников в сообщениях TO_EX() (т. е., любое сообщение TO_EX() трактуется, как TO_EX( {} )).

В режиме совместимости IGMPv1 маршрутизатор транслирует сообщения IGMPv1 и IGMPv2 в их эквиваленты IGMPv3:

Сообщение IGMP

Эквивалент IGMPv3

v1 Report

IS_EX( {} )

v2 Report

IS_EX( {} )

В дополнение к игнорированию сообщений IGMPv3 BLOCK и списков источников в TO_EX(), как в режиме совместимости IGMPv2, игнорируются сообщения IGMPv2 Leave и IGMPv3 TO_IN().

8. Список таймеров и счетчиков, значения по умолчанию

Многие из упомянутых здесь таймеров являются настраиваемыми. Если используются отличные от принятых по умолчанию настройки, они должны быть согласованными между всеми системами на одном канале. В описаниях ниже скобки используются для группировки выражений.

8.1. Переменная Robustness

Переменная Robustness обеспечивает возможность тонкой настройки в соответствии с ожидаемой частотой потери пакетов в сети. Если предполагается высокий уровень потерь, значение Robustness можно увеличить. Протокол IGMP устойчив к потере (Robustness — 1) пакетов. Для переменной Robustness недопустимо устанавливать значение 0 и не следует использовать значение 1. По умолчанию используется значение 2.

8.2. Интервал между запросами

Параметр Query Interval определяет интервал между сообщениями General Query, передаваемыми запрашивающим (Querier). По умолчанию используется интервал 125 секунд.

Меняя [Query Interval], администратор может регулировать число сообщений IGMP в сети. При увеличении интервала запросы IGMP будут передаваться реже.

8.3. Интервал между откликами

Значение Max Response Time используется для расчета кода Max Resp Code, включаемого в периодические сообщения General Query. По умолчанию используется значение 100 (10 секунд).

Меняя [Query Response Interval], администратор может настроить уровень всплесков для сообщений IGMP в сети. Большие значения будут снижать уровень всплесков трафика, поскольку отклики хостов будут распределены по более длинным интервалам. Число секунд, определяемое значением [Query Response Interval], должно быть меньше [Query Interval].

8.4. Интервал принадлежности к группе

Значение Group Membership Interval определяет интервал, по истечении которого групповой маршрутизатор может принять решение об отсутствии членов в группе или прослушивающих конкретный источник в сети.

Это значение должно быть равно ((Robustness ) * (Query Interval)) + (Query Response Interval).

8.5. Интервал присутствия других запрашивающих

Значение Other Querier Present Interval определяет интервал, по истечении которого групповой маршрутизатор может принять решение об отсутствии других групповых маршрутизаторов, которым следует быть запрашивающими. Это значение должно быть равно ((Robustness) * (Query Interval)) + (½ Query Response Interval).

8.6. Интервал стартового запроса

Значение Startup Query Interval определяет интервал между сообщениями General Query передаваемыми запрашивающим (Querier) при старте. По умолчанию используется значение 1/4 от Query Interval.

8.7. Счетчик стартовых запросов

Счетчик Startup Query Count показывает число стартовых запросов, разделенных интервалами Startup Query Interval. По умолчанию равно значению переменной Robustness.

8.8. Интервал запроса последнего участника

Параметр Last Member Query Interval определяет значение Max Response Time, используемое для расчета кода Max Resp Code, помещаемогов запросы Group-Specific Query, которые передаются в ответ на сообщения Leave Group. Он же определяет значение Max Response Time, используемое при расчете кода Max Resp Code для сообщений Group-and-Source-Specific Query. По умолчанию используется значение 10 (1 секунда).

Отметим, что для LMQI > 128 (12,8 сек.) может быть представлен ограниченный набор значений, соответствующих последовательным значениям Max Resp Code. При преобразовании заданного конфигурацией времени в Max Resp Code рекомендуется использовать, по возможности, точное значение или следующее меньшее значение, если запрошенное не имеет точного представления.

Это значение можно подстраивать для изменения «задержки» в сети. Меньшие значения уменьшают время обнаружения потери последнего участника группы или источника.

8.9. Счетчик запросов последнего участника

Значение Last Member Query Count определяет число запросов Group-Specific, передаваемых до того, как маршрутизатор примет решение об отсутствии локальных членов группы. Это же значение определяет число запросов Group-and-Source-Specific, передаваемых до того, как маршрутизатор примет решение об отсутствии получателей для конкретного источника. По умолчанию используется значение переменной Robustness.

8.10. Время запроса последнего участника

Last Member Query Time определяется произведением Last Member Query Interval и Last Member Query Count. Само значение не является настраиваемым, но его можно подобрать, меняя значения сомножителей.

8.11. Интервал незапрошенных отчетов

Значение Unsolicited Report Interval определяет временной интервал между повторами изначальных отчетов о принадлежности к группе. По умолчанию — 1 секунда.

8.12. Тайм-аут присутствия запрашивающего старой версии

Older Version Querier Interval определяет тайм-аут для возврата хоста в режим IGMPv3 после того, как он получил запрос старой версии. При получении такого запроса хосты устанавливают для своего таймера Older Version Querier Present Timer значение Older Version Querier Interval.

Это значение должно определяться выражением (Robustness) * (Query Interval из последнего запроса) + (Query Response Interval).

8.13. Интервал присутствия старых хостов

Older Host Present Interval определяет тайм-аут для возврата группы в режим IGMPv3 после того, как для этой группы был передан отчет старой версии. При получении такого отчета маршрутизаторы устанавливают для своего таймера Older Host Present Timer значение Older Host Present Interval.

Это значение должно определяться выражением (Robustness) * (Query Interval) + (Query Response Interval).

8.14. Настройка таймеров

В этом разделе приводятся рекомендации для сетевых администраторов по настройке описанных выше параметров в их сетях. Некоторые реализации маршрутизаторов могут устанавливать эти параметры динамически в соответствии с изменением характеристик сети.

8.14.1. Переменная Robustness

Переменная Robustness позволяет настроить IGMP в соответствии с ожидаемым уровнем потерь в канале. IGMPv3 сохраняет устойчивость при потере (Robustness — 1) пакетов. Например, если для переменной Robustness используется принятое по умолчанию значение 2, IGMPv3 будет устойчив к потере 1 пакета, но может работать не эффективно при более высоком уровне потерь. В подсетях со значительными потерями значение Robustness следует увеличивать с учетом ожидаемого уровня потери пакетов. Однако при увеличении значения переменной Robustness для подсети увеличивается время реакции на прекращение прослушивания источника или группы последним участником.

8.14.2. Интервал между запросами

Общий уровень периодического трафика IGMP обратно пропорционален значению Query Interval. Увеличение интервала между запросами снижает суммарный трафик IGMP. Значение Query Interval должно быть на меньше значения поля Max Response Time, помещаемого в сообщения General Query.

8.14.3. Максимальное время отклика

Всплески трафика IGMP обратно пропорциональны значению Max Response Time. Увеличение Max Response Time будет увеличивать интервалы между сообщениями Report, однако при больших Max Response Time в запросах Group-Specific и Source-and-Group-Specific будет возрастать время реакции на прекращение прослушивания источника или группы последним участником. Ожидаемая частота передачи сообщений Report может быть рассчитана путем деления ожидаемого числа передающих сообщения Report на величину Max Response Time. Значение Max Response Time может рассчитываться динамически с использованием ожидаемого числа отправителей отчетов для данного запроса в соответствии с приведенной таблицей.

Тип запроса

Ожидаемое число рапортующих

General Query

Все системы в подсети.

Group-Specific Query

Все системы в подсети, которые выразили заинтересованность в группе

Source-and-Group-Specific Query

Все системы в подсети, которые выразили заинтересованность в источнике и группе

Маршрутизатор не обязан рассчитывать число рапортующих или динамически подстраивать Max Response Time.

9. Вопросы безопасности

Рассматриваются воздействия поддельных сообщений каждого типа и описывается применение IPSEC AH для аутентификации сообщений, если она желательна.

9.1. Обманные сообщения Query

Обманное сообщение Query от машины, чей адрес IP меньше адреса текущего запрашивающего будет приводить к передаче функций Querier этой машине. Если обманщик больше не передает сообщений Query, отсчет таймера Other Querier Present на другом маршрутизаторе будет завершен через какое-то время и роль Querier будет возвращена. В течение срока действия обмана, если обманщик игнорирует сообщения Leave, трафик может поступать в пустые группы вплоть до [Group Membership Interval].

С помощью обманных запросов Group-and-Source-Specific может быть организована DoS-атака на хост. Атакующий может узнать о принадлежности конкретного хоста к группам с помощью обычного запроса. После этого он может отправить большое число запросов Group-and-Source-Specific, каждый из которых включает большое число источников и большое значение Maximum Response Time. Хост будет сохранять и поддерживать источники, указанные во всех этих запросах, пока не будет передан отложенный отклик. Это может приводить к значительному расходу памяти и ресурсов процессора для объединения записанных источников со списками источников, включенными в последующие запросы.

Для защиты от таких DoS-атак реализация хоста может ограничивать число запросов Group-and-Source-Specific в расчете на принадлежность к группе в течение интервала времени и/или записывать только ограниченное число источников.

Обманные запросы из локальной сети легко отследить. Для защиты от внешних запросов ниже даны 3 рекомендации:

  • маршрутизаторам не следует пересылать запросы; это проще обеспечить при наличии в запросах опции Router-Alert;

  • хостам следует игнорировать запросы версий 2 и 3 без опции Router-Alert;

  • хостам следует игнорировать сообщений General Query версий 1, 2 и 3, отправленные на групповой адрес, отличающийся от 224.0.0.1 (все системы).

9.2. Обманные сообщения Current-State Report

Обманные сообщения Report могут создавать у групповых маршрутизаторов ложные представления о наличии членов в группах, где реально никого нет. Обманные сообщения Report из локальной сети не имеют смысла, поскольку включение в группу не является привилегированной операцией и локальные пользователи могут добиться того же результата без применения обманных сообщений. Обманные сообщения Report из внешних источников представляют некоторую опасность. Ниже приведены два способа борьбы с такими сообщениями.

  • Игнорировать сообщения Report, если адрес отправителя не относится к сети, связанной с принявшим пакет интерфейсом. Это приводит к тому, что сообщения Report от мобильных хостов без адресов из локальной сети будут игнорироваться. Сообщения Report с адресом отправителя 0.0.0.0 следует воспринимать во всех случаях.

  • Игнорировать сообщения Report без опции Router Alert [RFC-2113] и требовать, чтобы маршрутизаторы не пересылали сообщений Report (это не является требованием обобщенной фильтрации на пути пересылки, поскольку в пакетах уже имеется опция Router Alert). Это решение не обеспечивает совместимости с реализациями IGMPv1 и ранними версиями IGMPv2, где не требуется опция Router Alert.

Обманное сообщение Report версии 1 может перевести маршрутизатор в состояние «присутствуют члены с версией 1» для конкретной группы, в результате чего маршрутизатор будет игнорировать сообщения Leave. Это может привести к передаче трафика в пустые группы на время до [Group Membership Interval]. Для решения этой проблемы можно ввести на маршрутизаторах конфигурационный параметр, обеспечивающий возможность полного игнорирования сообщений версии 1. Это решение будет блокировать автоматическую совместимость с хостами версии 1, поэтому его следует использовать лишь в ситуациях, где быстрый выход из группы имеет критически важное значение.

Обманное сообщение Report версии 2 может перевести маршрутизатор в состояние «присутствуют члены с версией 2» для конкретной группы, в результате чего маршрутизатор будет игнорировать сообщения IGMPv3 Source-Specific State. Это может вызывать потоки трафика из нежелательных источников в интервале времени до [Group Membership Interval]. Для решения этой проблемы можно ввести на маршрутизаторах конфигурационный параметр, обеспечивающий возможность полного игнорирования сообщений версии 2. Это решение будет блокировать автоматическую совместимость с хостами версии 2, поэтому его следует использовать лишь в ситуациях, где фильтрация источников имеет критически важное значение.

9.3. Обманные сообщения State-Change Report

Обманные сообщения State-Change Report могут заставить запрашивающего (Querier) передавать запросы Group-Specific или Source-and-Group-Specific для соответствующей группы. В результате на каждом маршрутизаторе и у всех членов группы будут выполняться ненужные операции, но нужный трафик теряться не будет. Для защиты от обманных сообщений State-Change Report имеется два способа, описанных ниже.

  • Игнорировать сообщения State-Change Report, если адрес их отправителя не относится к сети, связанной с принявшим пакет интерфейсом. В этом случае сообщения State-Change Report от мобильных хостов без адреса в локальной подсети будут игнорироваться. Сообщения State-Change Report с адресом отправителя 0.0.0.0 следует воспринимать на любом интерфейсе.

  • Игнорировать сообщения State-Change Report без опций Router Alert [RFC-2113] и требовать от маршрутизаторов отказа от пересылки сообщений State-Change Report (это не является требованием обобщенной фильтрации на пути пересылки, поскольку в пакетах уже есть опция Router Alert).

9.4. Использование IPSEC

В дополнение к описанным выше мерам может применяться IPSEC в режиме Authentication Header [AH] для защиты от удаленных атак. Этот метод позволяет убедиться в том, что сообщения IGMPv3 приходят от систем из ЛВС (точнее, от систем с правильным ключом). При использовании IPSEC сообщения, отправляемые по адресам 224.0.0.1 и 224.0.0.22 следует аутентифицировать с помощью AH. Применительно к ключам существует два варианта:

  1. Использование симметричного алгоритма цифровой подписи с одним ключом для всей ЛВС (или отдельным ключом для каждой группы). Это позволяет убедиться в том, что пакет отправлен системой, имеющей нужный ключ. Однако системы, имеющие верный ключ, могут отправлять и обманные сообщения, точная аутентификация на уровне отдельных отправителей не представляется возможной. Кроме того, в этом случае требуется запрет IPSec Replay Protection (защита от повторного использования пакетов).

  2. При разработке подходящего стандарта управления ключами можно использовать асимметричные алгоритмы цифровой подписи. Все системы должны знать открытые ключи всех маршрутизаторов, а маршрутизаторы — открытые ключи всех систем. Это требует множества операций по управлению ключами, но обеспечивает возможность аутентификации отдельного отправителя. Например, в результате использования такой защиты хост не сможет отправлять обманные сообщения, поскольку это будет разрешено только маршрутизаторам.

Описанное здесь решение напрямую применимо лишь к сообщениям Query и Leave в IGMPv1 и IGMPv2, поскольку сообщения Report передаются в группу, к которой они относятся, и не представляется возможным согласовать ключи для взаимодействия между хостами и маршрутизаторами для произвольных multicast-групп.

10. Согласование с IANA

Для всех типов IGMP, описанных в этом документе, значения уже выделены в [IANA-REG].

11. Благодарности

Авторы благодарны Ran Atkinson, Luis Costa, Toerless Eckert, Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark Handley, Bob Quinn, Michael Speer, Dave Thaler и Rolland Vida за их комментарии и предложения.

Отдельные фрагменты этого документа заимствованы из [RFC-1112] и [RFC-2236].

12. Нормативные документы

[AH] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 24029, November 1998.

[IANA-REG] http://www.iana.org/assignments/igmp-type-numbers

[RFC-1112] Deering, S., «Host Extensions for IP Multicasting», STD 5, RFC 1112, August 1989.

[RFC-2113] Katz, D., «IP Router Alert Option,» RFC 2113, February, 1997.

[RFC-2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC-2236] Fenner, W., «Internet Group Management Protocol, Version 2», RFC 2236, November 1997.

[RFC-3228] Fenner, B., «IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)», BCP 57, RFC 3228, February 2002.

13. Дополнительная литература

[RFC-1071] Braden, R., Borman, D. and C. Partridge, «Computing the Internet checksum», RFC 1071, September 1988.

[FILTER-API] Thaler, D., B. Fenner, and B. Quinn, «Socket Interface Extensions for Multicast Source Filters», Work in Progress10.

[SSM] Bhattacharyya, S., et. al., «An Overview of Source-Specific Multicast (SSM)», Work in Progress11.

[MLD] Deering, S., Fenner, W. and B. Haberman, «Multicast Listener Discovery (MLD) for IPv6», RFC 2710, October 1999.

[MLDV2] Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, and B. Haberman, «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», Work in Progress12.

Приложение A. Обоснования

A.1 Необходимость сообщений State-Change

IGMPv3 задает два типа отчетов о принадлежности к группам (Membership Report) — Current-State и State Change. В этом параграфе приведены обоснования использования обоих типов отчетов.

Маршрутизаторам требуется различать сообщения Membership Report, переданные в ответ на запросы от них и переданные в результате смены состояния на интерфейсе. Отчеты о принадлежности к группам, передаваемые в ответ на сообщения Membership Query служат главным образом для обновления имеющегося на маршрутизаторе состояния и само состояние при этом обычно не меняется. Передаваемые в ответ на смену состояния на интерфейсе сообщения Membership Report требуют от маршрутизаторы выполнения тех или иных действий (см. параграф 6.4).

Если не будет возможности различать эти два типа отчетов, маршрутизатор будет вынужден трактовать все сообщения Membership Report, как возможные смены состояния и это приведет к избыточной нагрузке на маршрутизатор, а также увеличит уровень трафика IGMP в сети.

A.2 Отмена отправки отчетов хостами

В IGMPv1 и IGMPv2 хост будет прекращать отправку ожидающих отчетов о принадлежности к группам, если увидит подобный отчет от другого члена группы в своей сети. В IGMPv3 такая возможность была удалена. Ниже приведены причины отказа.

  1. У маршрутизаторов может возникать потребность в отслеживании на своих интерфейсах статуса принадлежности к группам на уровне хостов. Это позволяет маршрутизаторам реализовать быстрый выход из групп (например, для многоуровневых систем контроля насыщения multicast-трафика), а также отслеживать принадлежность к группам в целях учета услуг.

  2. Подавление сообщений Membership Report недостаточно хорошо работает в ЛВС на основе мостов. Многие мосты и коммутаторы уровня 2 и 3, поддерживающие отслеживание IGMP (IGMP snooping), не пересылают сообщения IGMP в другие сегменты ЛВС для предотвращения «подавления отчетов». Отказ от такого подавления упростит работу таких устройств.

  3. Отказ от подавления отчетов о принадлежности к группам снизит число обрабатываемых хостами сообщений и, следовательно, упростит реализацию машины состояний.

  4. В IGMPv3 один отчет о принадлежности к группам содержит записи для множества multicast-групп в целях снижения числа передаваемых сообщений. В предыдущих версиях IGMP отчет для каждой группы передавался в отдельном сообщении.

A.3 Переключение режима фильтрации с EXCLUDE на INCLUDE

При наличии в сети для одной группы хостов с режимами фильтрации EXCLUDE и INCLUDE маршрутизатор должен использовать режим EXCLUDE (см. параграф 6.2.1). В режиме EXCLUDE маршрутизатор пересылает трафик от всех источников, за кроме тех, которые указаны в списке исключений. Если хостов с режимом фильтрации EXCLUDE больше нет, маршрутизатору желательно переключиться в режим INCLUDE без прерывания трафика остающихся получателей.

Одним из способов решения этой задачи является отслеживание маршрутизаторами всех источников, желаемых для хостов с режимом фильтрации INCLUDE, даже в тех случаях, когда сам маршрутизатор работает в режиме фильтрации EXCLUDE. Если отсчет таймера для группы завершается в режиме EXCLUDE, это означает, что в сети больше нет хостов с режимом EXCLUDE (иначе отчеты о принадлежности к группе от таких хостов обновляли бы таймер для группы). Маршрутизатор может аккуратно переключиться в режим фильтрации INCLUDE, сохранив источники, для которых в настоящее время выполняется пересылка, в своем списке источников.

Приложение B. Изменения по сравнению с IGMPv2

Хотя основным отличием IGMPv3 является добавление фильтрации источников, имеется еще ряд отличий от RFC 2236, перечисленных ниже.

  • Состояния поддерживаются для группы и списка источников, а не просто для группы, как в IGMPv2.

  • Взаимодействие с системами IGMPv1 и IGMPv2 определено, как операции с состоянием IGMPv3.

  • Изменен сервисный интерфейс IP для поддержки спецификаций списков источников.

  • Запрашивающий включает свои значения Robustness и Query Interval в пакеты Query для синхронизации этих переменных на системах, не являющихся Querier.

  • Max Response Time в сообщениях Query меняется экспоненциально в диапазоне от 25,5 секунд до 53 минут для использования на каналах с очень большим числом систем.

  • Хост повторяет сообщения о смене состояния для повышения отказоустойчивости.

  • Определены дополнительные разделы данных для будущих расширений.

  • Пакеты отчетов передаются по адресу 224.0.0.22 для обеспечения коммутаторам уровня 2 возможности «перехвата».

  • Пакеты отчетов могут содержать множество групповых записей с целью снижения числа передаваемых пакетов.

  • «Подавление» хостов больше не применяется с целью упрощения реализаций и обеспечения возможности явного отслеживания принадлежности к группам.

  • Новый флаг Suppress Router-Side Processing (S) в сообщениях Query решает проблему отказоустойчивости в присутствии IGMPv2.

Адреса авторов

Brad Cain

Cereva Networks

Steve Deering

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA 95134-1706

Phone: +1-408-527-8213

EMail: deering@cisco.com

Bill Fenner

AT&T Labs — Research

75 Willow Rd.

Menlo Park, CA 94025

Phone: +1-650-330-7893

EMail: fenner@research.att.com

Isidor Kouvelas

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA 95134-1706

Phone: +1-408-525-0727

EMail: kouvelas@cisco.com

Ajit Thyagarajan

Ericsson IP Infrastructure

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Internet Group Management Protocol.

2Source-Specific Multicast.

3Multicast Listener Discovery — обнаружение прослушивающих групповой трафик устройств.

4Querier’s Robustness Variable — значение отказоустойчивости запрашивающего.

5Querier’s Query Interval Code — код интервала между запросами.

6Querier’s Query Interval — интервал между запросами.

7Group Membership Interval.

8Last Member Query Time.

9Этот документ признан устаревшим и заменен RFC 4302. Прим. перев.

10Работа завершена и опубликована в RFC 3678. Прим. перев.

11Работа завершена и опубликована в RFC 3569. Прим. перев.

12Работа завершена и опубликована в RFC 3810. Прим. перев.




RFC 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures

Network Working Group                                    M. Mealling
Request for Comments: 3405                                  VeriSign
BCP: 65                                                 October 2002
Category: Best Current Practice

Система DDDS. Часть 5 – процедуры присваивания URI.ARPA

Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA

Assignment Procedures

PDF

Статус документа

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

Этот документ является пятым в серии, полностью описанной в Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401). Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Оглавление

Исключено из версии HTML

1. Введение

Этот документ определяет правила и процедуры добавления записей NAPTR1 в зоны URI.ARPA и URN.ARPA с целью преобразования идентификаторов URI2 в соответствии со спецификацией Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application (RFC 3402) [2], которая задает Приложение, использующее Базу данных DDDS на основе DNS3. Все эти концепции определены в RFC 3401 [1]. Важно отметить, что корректное понимание этого документа невозможно без прочтения RFC 3401 и указанных там документов.

RFC 3403 определяет использование DNS в качестве Базы данных DDDS, содержащей правила передачи полномочий для URI (иногда эти правилами называют указаниями по преобразования). Этот документ указывает, что первым шагом алгоритма является добавление суффикса ‘URI.ARPA’ к схеме URI и нахождение записи NAPTR для полученного доменного имени. Т. е., первым шагом преобразования http://foo.com/ будет поиск записи NAPTR для домена http.URI.ARPA. Преобразование URN поддерживает похожую процедуру, используя в качестве корневой зону ‘URN.ARPA’. В этом документе описаны процедуры вставки новых правил в зоны ‘URI.ARPA’ и ‘URN.ARPA’.

2. Преобразование URI и преобразование URN

RFC 3402 [2] определяет как работают преобразования URI [7] и URN [6], когда используется DNS в качестве базы данных правил передадачи полномочий (или указаний). В частности, этот документ говорит, что начальные инструкции (указания) для преобразования URI на основе DNS хранятся как записи о ресурсах зоны DNS ‘URI.ARPA’.

Поскольку URN является схемой URI, указание по преобразованию для URI-префикса ‘urn:’ также будет храниться в зоне ‘URI.ARPA’. Это правило говорит, что пространство имен [6] преобразуется путем добавления суффикса ‘URN.ARPA’ и результат используется в качестве ключа при поиске записи NAPTR [4].

3. Правила регистрации

Создание данной схемы URI или пространтсва имен URN (NID4) выполняется в соответствии с подходящими документами по регистрации. Схемы URI регистрируются по Registration Procedures for URL Scheme Names (RFC 2717) [10]. Пространства имен URN регистрируются по «URN Namespace Definition Mechanisms» (RFC 2611) (или обновленной версии) [9].

3.1 Регистрация URI.ARPA

3.1.1 Разрешены только схемы из дерева IETF

Для включения в зону URI.ARPA соответствующая схема URI должна быть зарегистрирована в дереве IETF URI. Требования для этого дерева содержатся в документе [10].

3.1.2 Сначала регистрируются схемы

Недопустимо регистрировать запись NAPTR для схемы URI до регистрации самой схемы и публикации стабильной спецификации в соответствии с [10]. IESG или указанный эксперт будут проверять запрос на предмет

  1. корректности и технической обоснованности;
  2. совместимости с опубликованными спецификациями URI;
  3. того, что что записи NAPTR для базирующихся на DNS URI не передают полномочия преобразования никому, кроме держателя имени DNS;

Последнее правило нужно для того, чтобы данное указание по преобразованию URI не было перехватывало (по неосторожности или по иным причинам) сетевой трафик для данного домена.

3.1.3 Регистрация NAPTR может сопровождать регистрацию схемы

Запрос на регистрацию URI.ARPA может сопровождать запрос на регистрацию схемы URI (согласно [10]) и в таких случаях оба запроса вместе рассматриваются IESG или назначенными экспертами.

3.1.4 Регистрация изменений после регистрации схемы

Запрос на регистрацию записи NAPTR (или на изменение существующей записи NAPTR) может быть подан после того, как зарегистрирован префикс URI. Если спецификация префикса URI контролируется не IETF, IESG будет требовать одобрения владельца спецификации или поддерживающей ее стороны до того, как будет произведена регистрация. Это требование является дополнением к обычному техническому обзору при регистрации NAPTR, выполняемому IESG или назначенными экспертами.

3.2 Регистрация URN.ARPA

3.2.1 Сначала регистрация NID

Недопустимо регистрировать запись NAPTR для URN NID до регистрации NID и публикации стабильной спецификации в соответствии с [9]. Это делается для предотвращения регистрации записи NAPTR в URN.ARPA в обход процесса регистрации NID.

3.2.2 Регистрация NAPTR может сопровождать регистрацию NID

Запрос на регистрацию URN.ARPA может сопровождать запрос на регистрацию NID (в соответствии с [9]) и оба запросабудут рассматриваться вместе.

3.2.3 Регистрация или изменение после регистрации схемы

Запрос на регистрацию записи NAPTR (или на изменение существующей записи NAPTR) может быть подан после регистрации NID. Если спецификация NID контролируется не IETF, IESG будет требовать одобрения владельца спецификации или поддерживающей ее стороны до того, как будет произведена регистрация. Это требование является дополнением к обычному техническому обзору при регистрации NAPTR, выполняемому IESG или назначенными экспертами.

Отметим, что это применимо ко всем записям NAPTR для конкретного NID, даже если запись NAPTR может оказывать воздействие только на часть пространства URN, выделенного для NID

4. Требования к указаниям

Делегирование пространства имен может происходить двумя путями. Для большинства URI делегируемый ключ будет жестко определяться самим идентификатором (например, имя хоста для HTTP URI). Синтаксис местоположения ключа в этом случае предопределен синтаксисом схемы. В других случаях новый ключ может быть частью самого указания. Функциональный эквивалент этого можно выразить словами “если данное правило выполняется, оно всегда является ключом».

Для минимизации нагрузки по запросам в зоны URI.ARPA и URN.ARPA предлагается устанавливать для этих зон экстремально большое время жизни TTL (возможно, измеряемое годами).

Таким образом, для любого префикса URI или пространства имен URN, в которых указания по преобразованию будут склонны к изменению, актуальные правила следует хранить в какой-либо другой (менее статичной) зоне DNS, а в зоне URI.ARPA или URN.ARPA следует использовать стабильную запись NAPTR, которая будет служить для передачи полномочий в менее статичную зону.

Например пространство имен URN ‘foo’ имеет гибкие правила передачи полномочий. Вместо включения этих правил в зону URN.ARPA туде помещается запись, передающая полномочия хранения этих правил серверу имен с меньшим временем жизни записей. Такая запись в зоне URN.ARPA будет иметь вид:

foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com.

Когда клиент начинает процесс преобразования. Он сначала будет запрашивать foo.URN.ARPA для получения показанной выше записи, а на втором этапе будет запрашивать ‘urn-resolver.foo.com’ для получения записей NAPTR, содержащих правила преобразования. TTL на корневом уровне имеет очень большое значение. Значение TTL в ‘urn-resolver.foo.com’ значительно меньше.

Схема URI ‘http’, напротив, жестко придерживается определенного синтаксиса, который указывает, что искомый хост задан в самом значении URI. Поскольку этот синтаксис не меняется, правило можно включать в зоеу URI.ARPA. Запись будет иметь вид:

http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" .

Таким образом, второй шаг преобразования будет заключаться в использовании доменного имени из URI в качестве следующего ключа в цикле. Если, например, данная запись NAPTR является завершающей и содержит некое имя хоста в поле replacement, клиент может обращаться к этому хосту с запросом о данном URI.

5. Процедура подачи

Используя регистрационный механизм MIME Content-Type [8] в качестве успешной модели регистрации, процедуры ‘URI.ARPA’ и ‘URN.ARPA’ поддерживают шаблон запроса, подаваемого заинтересованной стороной в открытый список рассылки. Если в течение двух недель не поступило ни одного возражения, представители регистрационного агентства считают подачу состоявшейся и вводят соответствующую информацию в пространство имен.

  • Для регистрации в зоне ‘URI.ARPA’ запросы направляются по адресу ‘register@URI.ARPA’.

  • Для регистрации в зоне ‘URN.ARPA’ запросы направляются по адресу ‘register@URN.ARPA’.

В качестве регистрационного агентства выступает IANA5.

В качестве возражений принимаются те, которые отмечают влияние на саму зону или DNS в целом. Возражения по схеме URI или пространству имен URN NID не допускаются, поскольку их следует обсуждать в соответствующих форумах. Логическим следствием из этого является то, что должна разрешаться регистрации любых санкционированных схем URI и пространств имен URN, если они соответствуют требованиям данного документа в части времени жизни и общего влияния на DNS.

6. Регистрационный шаблон

Шаблон, направляемый для регистрации в соответствующий список рассылки должен включать:

6.1 Ключ

Это значение URN NID или схемы URI, используемое в качестве доменной части запроса DNS. Ключ должен быть корректен с точки зрения процедур, указанных в документах по распределению пространства имен URN, а также все новым стандартам по регистрации новых схем URI.

6.2 Полномочность

Персона или организация (объект), имеющая полномочия на регистрацию записи. Эти полномочия должны быть признаны IESG или относится к числу указанных в документах по регистрации URN NID [9] или схем URI [10].

6.3 Записи

Актуальные записи DNS, представляющие набор правил для ключа. Требуемыми полями являются Preference, Order, Flags, Services, Regex и Replacement, определенные в документе RFC 3404 [4].

7. Пример шаблона

To: register@URN.ARPA
From: joe@foo.com

Key: foo
Authority: Foo Technology, Inc as specified in RFCFOO
Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com.

8. Регистрация URN в зоне URI.ARPA

Поскольку в этом документе обсуждаются зоны URI.ARPA и URN.ARPA, а правило URN существует в зоне URI.ARPA, это делает осмысленным приведенное ниже правило URI при регистрации URN.

To: register@URI.ARPA
From: The IETF URN Working Group

Key: urn
Authority: RFC2141
Record: urn IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\2/i" .

9. Согласование с IANA

Агентство IANA создало зоны URN.ARPA и URI.ARPA. Иерархическая структура имен и использование имен только из этих зон обеспечивают возможность использования ключей, описанных в параграфе 6.1 этого документа. Администрирование и текущее управление для этих зон принимает на себя IANA. Записи DNS, включаемые в эти зоны, регистрируются, как описано в этом документе.

Агентство IANA также создало две почтовых конференции (списки рассылок) register@uri.arpa и register@urn.arpa для регистрации в соответствии с данным документом. Списками также управляет IANA.

10. Вопросы безопасности

Зоны ‘uri.arpa’ и ‘urn.arpa’ могут служить объектами DoS-атак6 и подмен (spoofing) для изменения путей передачи полномочий. Любому объекту с сервером имен, на котором поддерживаются эти зоны, следует предпринять соответствующие меры по защите этих важных компонент инфраструктуры Internet. Когда станет возможным использование серверами имен цифровых подписей, записи из этих зон также следует подписывать.

11. Благодарности

Автор выражает свою признательность Ron Daniel, который был соавтором изначального варианта этого документа. Вклад Рона в разработку модели правил передачи полномочий сделал возможными описанные здесь процедуры и саму систему DDDS.

12. Литература

[1] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS», RFC 3401, October 2002.

[2] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.

[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[4] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application», RFC 3404, October 2002.

[5] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures», RFC 3405, October 2002.

[6] Moats, R., «URN Syntax», RFC 2141, November 1998.

[7] Berners-Lee, T., Fielding, R. and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396, August 1998.

[8] Freed, N., Klensin, J. and J. Postel, «Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures», BCP 13, RFC 2048, November 1996.

[9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, «URN Namespace Definition Mechanisms», BCP 33, RFC 2611, October 1998.

[10] Petke, R. and I. King, «Registration Procedures for URL Scheme Names», BCP 35, RFC 2717, January 1999.

13. Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

US

EMail: michael@neonym.net

URI: http://www.verisignlabs.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

14. Полное заявление авторских прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Naming Authority Pointer — указатель на уполномоченный сервер именования

2Uniform Resource Identifiers – однотипные идентификаторы ресурсов

3Domain Name System – система доменных имен.

4Namespace id.

5Internet Assigned Numbers Authority – агентство по присвоению значений для Internet.

6Denial of Service – атака, направленная на отказ служб.




RFC 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application

Network Working Group                                    M. Mealling
Request for Comments: 3404                                  VeriSign
Obsoletes: 2915, 2168                                   October 2002
Category: Standards Track

Система DDDS. Часть 4 – Приложение для преобразования URI.

Dynamic Delegation Discovery System (DDDS)

Part Four: The Uniform Resource Identifiers (URI)

Resolution Application

PDF

Статус документа

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

Этот документ описывает спецификацию приложения для поиска информации о URI1 путем определения полномочных серверов по значению URI. Данный метод используется для того, чтобы показать, что полномочный сервер относится к системе DDDS2.

Документ также является частью серии, полностью указанной в документе Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401). Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Оглавление

Исключено из версии HTML

1. Введение

Система DDDS обеспечивает возможность организации связей между строками данных для поддержки систем передачи полномочий (делегирования) с динамической конфигурацией. Работа DDDS основана на отображении некой уникальной строки на данные, хранящиеся в Базе данных DDDS путем итеративного применения правил преобразования строк до выполнения условий завершения.

Этот документ описывает Приложение DDDS для преобразования идентификаторов URI. Документ не определяет Алгоритм и Базу данных DDDS. Серия документов, которая задает эти спецификации, указана в документе Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) [1]. Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Идентификаторы URI обеспечивают значительные преимущества при поиске ресурсов, доступных через Internet. Однако в процессе работы с этими идентификаторами было обнаружено множество проблем. Рабочая группа Uniform Resource Identifier предложила разработку URN3 [8] для использования в качестве постоянных и не зависящих от места расположения идентификаторов ресурсов Internet. Эти идентификаторы позволяют решить большинство проблем, возникающих при использовании URI. В RFC 1737 [6] были определены требования к URN.

В течение срока работы группы URI-WG было внесено множество предложений по URN. В процессе разработки этих предложений происходило несколько встреч, приведших к выработке компромиссного решения, известного как Knoxville framework. Основным результатом схемы Knoxville является то, что система преобразования должна быть отделена от пути присваивания имен. Это расходится с большинством URI, которые указывают хост для контакта и используемый протокол. Читателям рекомендуется обратиться к работе [7], содержащей информацию о схеме Knoxville, а также о контексте и целях этого предложения.

Разделение путей преобразования и и создания имен обеспечивает несколько преимуществ. Возможно использование множества вариантов именования и преобразования, а также использование различных протоколов и преобразователей (resolver). Но в связи с разделением возникает одна проблема – как преобразовать имя, когда оно не указывает нам направление на преобразователь имен?

На первый взгляд система DNS4 представляется основным кандидатом для схемы преобразования, поскольку эта система широко распространена и понятна. Однако DNS не подходит для поддержки информации на поресурсной основе. Прежде всего, система DNS никогда не была рассчитана на обслуживание столь большого числа записей. Во-вторых, ограниченный размер записи не подходит для каталожной информации. В-третьих, доменные имена не подходят для URN.

В результате здесь предлагается использовать DDDS для поиска «преобразователей», которые могут обеспечить информацию об отдельном ресурсе, потенциально включая сам этот ресурс. Для достижения цели мы «перепишем» URI в Ключ, следуя правилам, полученным с помощью DDDS. В этом документе описывается URI Resolution, как приложение DDDS и задается спецификация использования по крайней мере одной Базы данных на основе DNS.

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119.

Все прочие термины, особенно выделенные шрифтом, заимствованы из спецификации алгоритма DDDS в RFC 3403 [3].

3. Различия между URN и URI

С точки зрения данной системы теоретически разница между URI в общем случае и URN в специальном случае отсутствует. На практике же существует разница, которая сдерживает распространение URI. Если преобразование URN коллапсирует в базовое преобразование URI, системы URN могут пострадать от недостатков адаптации преобразования URI.

Решение состоит в дозволении сокращать преобразование URN. В приведенной далее спецификации базовое преобразование URI начинается со вставки правил для известных схем URI в реестр ‘uri.arpa.’. Для схемы ‘URN:’ одно из правил, найденных в ‘uri.arpa.’, будет для схемы ‘urn’. Это правило будет просто передавать полномочия зоне ‘urn.arpa.’ для получения дополнительных записей NAPTR на основе пространства имен URN. Существенным является то, что Правило перезаписи URI Resolution для ‘URN:’ является Первым общеизвестным правилом для Приложения URN Resolution.

Следовательно, этот документ содержит спецификации двух Приложений DDDS. Одна спецификация относится к URI Resolution, а другая – к URN Resolution. Обе спецификации технически идентичны, но разделение обеспечивает возможность независимой обработки.

4. Спецификации приложений для преобразования URI и URN

Этот шаблон определяет Приложение DDDS по преобразованию URI и URN, согласно правилам и требованиям документа [3]. База данных DDDS, используемая этим Приложением, описана в документе [4], который определяет тип записей NAPTR5 в системе DNS.

4.1 Уникальная строка Приложения

Строкой AUS6 служит URI или URN, для которого отыскивает полномочный сервер. Эти URI или URN должны быть в каноническом представлении и представляться в 16-ричном виде согласно «absolute-uri» из документа Collected ABNF (RFC 2396) [15].

4.2 Первое общеизвестное правило

В случае URI первый известный ключ создается путем выполнения схемы URI. В случае URN первым известным ключом является Namespace Identifier. Например, для URI ‘http://www.example.com/’ первым Ключом будет http. Для URN ‘urn:foo:foospace’ первым Ключом будет ‘foo’.

4.3 Флаги

В настоящее время определены только 4 флага — S, A, U и P. Флаги S, A и U используются для завершающего просмотра. Это означает, что Правило является последним и флаг определяет, что будет происходить на следующем этапе. Флаг S означает, что выводом данного Правила является доменное имя, для которого существует одна или несколько записей SRV [9]. Использование типа SRV для преобразования URI и URN рассматривается в главе 5. Флаг A означает, что выводом Правила является доменное имя и следует использовать для этого домена поиск записи типа A, AAAA или A6. Флаг U говорит, что выводом Правила является URI [15].

Флаг P говорит, что оставшаяся часть Алгоритма DDDS игнорируется, а дальнейший процесс зависит от приложения вы выходит за рамки данной спецификации. Приложение может использовать компоненту Protocol, найденную в поле Services, для связанного с Приложением набора правил, который следует выполнять далее. Запись с флагом P является последней записью, которая интерпретируется правилами настоящего документа. Можно трактовать флаг P, как индикатор завершающего поиска, но это будет некорректно, поскольку “завершающее” Правило является концепцией DDDS, а этот флаг показывает, что дальнейшее просто не имеет отношения к DDDS.

Оставшиеся алфавитные флаги зарезервированы для будущих версий данной спецификации. Цифровые флаги могут использоваться для локальных экспериментов. Флаги S, A, U и P являются взаимоисключающими и библиотеки преобразования могут генерировать сообщение об ошибке при обнаружении противоречивых флагов (экспериментальный код и программы для помощи при создании Правил перезаписи будут генерировать такие сообщения с большей вероятностью, нежели клиентские программы типа браузеров). Предполагается, что в будущем может быть разрешено включение множества флагов, поэтому для реализаций недопустимо предполагать, что поле флагов не может содержать более 1 символа. Если клиент считает, что в записи содержится неизвестный флаг, он должен игнорировать такой флаг и перейти к следующему Правилу. Такая проверка имеет более высокий приоритет, нежели какое-либо упорядочение, поскольку флаги могут управлять интерпретацией полей. Новый флаг может изменить интерпретацию поля regexp и/или replacement так, что станет невозможно определить соответствие записи данной цели.

Флаги S, A и U называются завершающими (terminal), поскольку они прерывают цикл выполнения алгоритма DDDS. Если эти флаги отсутствуют, клиент может предполагать существование другого Правила для Ключа, произведенного текущим Правилом перезаписи.

4.4 Параметры сервиса

Параметры сервиса для этого Приложения имеют форму строки символов, следующей приведенной ниже форме ABNF

service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM
; Поля protocol и rs fields ограничены 32 символами и должны начинаться с буквы.

Иными словами, за необязательной спецификацией протокола может следовать 0 или более служб преобразования. Каждый сервис преобразования указывается начальным символом ‘+’.

Допускаются также пустые строки. Они обычно будут появляться в начале последовательности Правил, когда невозможно узнать, какие службы и протоколы будут предложены в конце конкретного пути передачи полномочий.

4.4.1 Службы

Идентификаторы сервиса, указываемые в поле rs, совпадают для преобразований URI и URN, поскольку сами типы входных значений основаны на схеме URI. Список корректных служб определен в документе [11].

Примерами сервиса могут служить:

I2L: по данному URI возвращается идентификатор URI, указывающий место, где был найден исходный идентификатор URI.

I2Ls: по данному URI возвращается один или множество идентификаторов URI, указывающих места, где можно найти исходный URI.

I2R: по данному URI возвращается один экземпляр ресурса, указанного данным URI.

I2Rs: по данному URI возвращается один или множество экземпляров ресурсов, указываемых данным URI.

I2C: по данному URI возвращается один экземпляр описания ресурса.

I2N: по данному URI возвращается одно имя URN, которое именует ресурс (Отметим, что эквивалентность применительно к URN является нетривиальным вопросом; см. документ [6], объясняющий причины этого).

4.4.2 Протоколы

Идентификаторы протоколов, которые являются корректными значениями поля Protocol, должны определяться документами, относящимися к преобразованию URI. В настоящий момент единственным таким протоколом является THTTP [10].

Очень важно обеспечить, чтобы простого указания протокола в поле Services было недостаточно, поскольку имеется дополнительная семантика, относящаяся к преобразованию URI, которая не определена в протоколе. Например, если протокол Z39.50 указан в качестве корректного, нужно будет дополнительно определить как этот протокол будет представлять запросы для конкретных служб, как будут представляться идентификаторы URI и какая информация будет возвращаться.

4.4.3 Применимость сервиса

В силу возможности существования сложных наборов возможных протоколов и служб, у приложений часто может возникать необходимость использования более сложного процесса выбора, нежели простой просмотр упорядоченного списка протоколов. Например, при наличии 4 применимых правил в последнем значение поля Service может оказаться более предпочтительным, чем в первом. Но, поскольку клиент может быть удовлетворен первым, он просто не узнает о четвертом, который может оказаться “лучше”.

Для упрощения этой задачи у клиента может возникнуть желание несколько изменить алгоритм DDDS (только для данного приложения!), чтобы определять наличие более предпочтительных протоколов и/или служб. Это можно сделать без опасений для данного приложения, используя более сложные итерации между п. 3 и п. 4 алгоритма DDDS для поиска оптимального пути. Например, после того, как клиент нашел правило, в котором Выражение для замены (Substitution Expression) дает результат с подходящим описанием сервиса, клиент может отметить этот факт и продолжить просмотр правил (в порядке, заданном значением Order!) для поиска наилучшего. Если лучшего правила не будет найдено, клиент сможет использовать отмеченное ранее правило.

Следует принимать во внимание, что для безопасной реализации сказанного входные данные п. 3 и выходные данные п. 4 должны быть идентичны базовому алгоритму. Для клиентской программы недопустимы попытки проведения оптимизации за пределами одного набора Правил перезаписи (т. е., со сменой путей передачи полномочий).

4.5 Корректные базы данных

В настоящий момент для Приложения задана только одна База данных DDDS. Документ Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database (RFC 3403) [4] говорит, что это База данных DDDS Database, которая использует DNS-записи NAPTR для хранения правил перезаписи. Ключи для базы данных представляются как доменные имена.

Выводом First Well Known Rule для Приложения URI Resolution является схема URI. Для преобразования этого вывода в уникальный ключ Базы данных к результату в конце добавляется строка ‘.uri.arpa.’. Полученное в результате доменное имя используется для запроса записей NAPTR, порождающих новые ключи в формате доменных имен.

Выводом First Well Known Rule для Приложения URN Resolution является идентификатор из пространства имен URN. Для преобразования его в ключ в конце идентификатора добавляется строка ‘.urn.arpa.’. Полученное доменное имя используется для запроса записей NAPTR, которые порождают новые ключи в форме доменных имен.

Серверы DNS могут интерпретировать значения Flag и использовать полученную информацию для включения соответствующих записей SRV и A в раздел Additional Information пакета DNS. Клиентам рекомендуется (но не требуется) проверять дополнительную информацию. Более подробное описание работы с разделом Additional Information и записями в откликах DNS можно найти в RFC 34037.

Для представления выражений для замены используется набор символов UTF-8. На входе допускаются все символы, которые могут встречаться в URI. Для Ключей допустимы те символы, которые разрешены в доменных именах DNS. Флаг «i» в выражениях для замены служит для обозначения того, что проверка соответствия выполняется без учета регистра символов.

5. Примеры

5.1 Пример использования URN

Рассмотрим URN из гипотетического пространства имен FOO. Номера FOO служат идентификаторами приблизительно для 30 миллионов зарегистрированных компаний по всему миру; идентификаторы распределяет и поддерживает компания Fred, Otto and Orvil, Inc. URN могут иметь вид:

urn:foo:002372413:annual-report-1997

Первым шагом процесса преобразования будет поиск информации о пространстве имен FOO. Идентификатор пространства имен [8] «foo» создается из URN путем добавления к ‘.urn.arpa.’ префикса ‘foo’, что дает в результате ‘foo.urn.arpa.’. Далее делается запрос к DNS для получения записей NAPTR для этого домена. Результат запроса имеет вид:

foo.urn.arpa.
   ;; order pref flags service regexp replacement
   IN NAPTR 100 10 "s" "foolink+I2L+I2C" "" foolink.udp.example.com.
   IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.example.com.
   IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.example.com.

Поле order содержит одинаковые значения, показывающие отсутствие упорядочения. Поле preference показывает, что провайдер предпочитает, чтобы клиенты использовали специальный протокол foolink, после этого RCDS и в последнюю очередь THTTP. Все записи содержат флаг s, показывающий, что запись является завершающей и следующим шагом является получение от DNS записи SRV для данного доменного имени.

Поле service говорит, что при использовании протокола foolink можно вводить запросы I2L, I2C или I2R для получения URI или задавать некоторые более сложные вопросы о ресурсе. Можно использовать сервис RCDS8 [12] для получения некоторых метаданных, тогда как THTTP можно использовать для получения URI, соответствующего текущему местоположению ресурса.

Предположим, что клиент не знает протокола foolink, но знает RCDS. Следующим шагом будет поиск записей SRV RR для имени rcds.udp.example.com, котрый даст нам список хостов, способных предоставить требуемые услуги преобразования. Этот список может иметь вид:

;; Pref Weight Port Target
   rcds.udp.example.com IN SRV 0 0 1000 deffoo.example.com.
   IN SRV 0 0 1000 dbexample.com.au.
   IN SRV 0 0 1000 ukexample.com.uk.

Список содержит три хоста, способных выполнить преобразование и указывает номер порта, который следует использовать для связи с сервером RCDS (получить сведения об интерпретации приведенных выше полей можно из спецификации SRV [9]). Здесь существует возможность оптимизации. RFC 34039 определяет возможность использования раздела Additional Information. В этом случае записи SRV могут возвращаться в качестве дополнительной информации при завершающем поиске NAPTR (вместе с записями A для этих SRV). Эти записи обеспечивают возможность существенной оптимизации. При использовании этого в комбинации со большими значениями TTL для записей *.urn.arpa. среднее число обращений к DNS для преобразования большинства URI будет приближаться к 1.

Отметим, что приведенные выше примеры записей NAPTR предназначены для представления результатов поиска NAPTR с использованием некой клиентской программы типа nslookup; администраторам зон следует поддерживать документацию для своих серверов имен с точной информацией о синтаксисе используемых файлов зон.

Отметим также, что может использоваться дополнительный первый шаг, на котором URN преобразуется как базовый вариант URI путем просмотра urn.uri.arpa. Результирующее правило будет задавать, что NID выделяется и URN и суффикс ‘.urn.arpa.’ добавляется для получения первого ключа ‘foo.urn.arpa.’.

5.2 Пример схемы CID URI

Рассмотрим схему URI на основе MIME Content-Id. URI может иметь вид:

cid:199606121851.1@bar.example.com

(отметим, что этот пример выбран с учебными целями и не соответствует схеме CID URI).

Первым шагом процесса преобразования будет нахождение схемы CID. Эта схема выделяется из URI путем добавления в конце суффикса ‘.uri.arpa.’ и поиска NAPTR для имени ‘cid.uri.arpa.’. Результат может иметь вид:

cid.uri.arpa.
   ;; order pref flags service regexp replacement
   IN NAPTR 100 10 "" "" "!^cid:.+@([^\.]+\.)(.*)$!\2!i" .

Поскольку здесь имеется лишь одна запись, упорядочение не представляет проблемы. Поле replacement пусто, поэтому используется шаблон, указанный в поле regexp. Это регулярное выражение применяется ко всему значению URI для проверки соответствия и дает позитивный результат. Компонента \2 выражения для замены возвращает строку «example.com». Поскольку поле флагов пусто, поиск не является завершающим и далее следует запрос к DNS для получения новых записей NAPTR, связанных с доменом ‘example.com’.

Отметим, что правило не выделяет полное доменное имя из CID, предполагая, что CID происходит от хоста и выделяя доменное имя этого хоста. Хотя все хосты (такие, как bar) иогут иметь свои собственные записи NAPTR, поддержка независимых записей для всех хостов сайта может оказаться слишком обременительной. Шаблоны здесь не подходят, поскольку их использование будет возвращать результат лишь при отсутствии точного соответствия имен в системе.

Записи, возвращенные по запросу для имени example.com, могут иметь вид:

example.com.
   ;; order pref flags service regexp replacement
   IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" z3950.tcp.example.com.
   IN NAPTR 100 50 "s" "rescap+I2C" "" rescap.udp.example.com.
   IN NAPTR 100 50 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.example.com.

Продолжая рассмотрение этого примера, отметим, значения поля order совпадают для всех записей и клиент может выбрать любую запись. Приложение определяет флаг ‘s’ как признак завершения поиска и указания на то, что результатом перезаписи будет доменное имя, для которого следует запросить запись SRV. Когда клиент сделает такой запрос, он получит информацию о хосте, номере порта, протоколе и службах, доступных по этому протоколу. Этой информации клиенту достаточно для контакта с сервером и запроса у него информации о CID URI.

Напомним, что в регулярном выражении последовательность \2 служит для выделения доменного имени из CID, а \. для соответствия символам точки, разделяющим компоненты доменного имени. Поскольку ‘\’ используется в качестве escape-символа, вхождение этого символа как литерала должно использовать дополнительный escape-символ ‘\’. Для приведенной выше записи cid.uri.arpa регулярное выражение в master-файле должно иметь форму «!^cid:.+@([^\\.]+\\.)(.*)$!\\2!i». Когда клиентская программа получает запись, шаблон преобразуется в «!^cid:.+@([^\.]+\.)(.*)$!\2!i».

5.3 Преобразование для схемы HTTP URI

Даже при широком развертывании систем URN сохранится значительное число URI, связанных с хостами. Следует обеспечить возможность разработки систем преобразования URI, способных независимо определять местоположение для таких URI.

Предположим, что имеется URI для весьма популярной программы, которую желательно опубликовать на многочисленных зеркалах по всему миру:

http://www.example.com/software/latest-beta.exe

Мы выделяем префикс «http» и ищем записи NAPTR для ‘http.uri.arpa.’. Результат может иметь вид:

http.uri.arpa. IN NAPTR
;; order pref flags service regexp replacement
100 90 "" "" "!^http://([^/:]+)!1!i" .

Это выражение возвращает все символы, расположенные между двойной дробной чертой (//) и следующей дробной чертой или двоеточием. Для разграничения компонент выражения для замены используется восклицательный знак ‘!’, поскольку в противном случае пришлось бы использовать escape-символы \ перед символами / и регулярное выражение для зоны имело бы вид:

"/^http:\\/\\/([^\\/:]+)/\\1/i"

Применим шаблон к URI для извлечения www.example.com и найдем для этого имени записи NAPTR:

www.example.com.
   ;; order pref flags service regexp replacement
   IN NAPTR 100 100 "s" "thttp+L2R" "" thttp.example.com.
   IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.example.com.

Найдем записи SRV для thttp.example.com, которые будут содержать информацию о хостах, которые домен example.com указал в качестве зеркал. Клиентская программа может указать пользователю один из таких хостов.

6. Примечания

  • Процедуры регистрации для зон DNS ‘urn.arpa.’ и ‘uri.arpa.’ описаны в документе «Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures» (RFC 3405 [5].

  • Если запись с определенным значением поля order соответствует URI, но клиенту не известен указанный в записи протокол и сервис, клиенту следует продолжить просмотр записей с таким же значением поля order. Для клиента в этом случае недопустимо рассматривать записи с большими значениями поля order. Это необходимо для обеспечения работоспособности при частичной передаче полномочий для зоны. Поле order позволяет администраторам сказать: “Все запросы для URI, соответствующие шаблону x, ведут к серверу 1, а все прочие – к серверу 2″.

  • Отметим, что записи SRV RR предъявляют к клиентам дополнительные требования.

7. Согласование с IANA

Использование зон «urn.arpa.» и «uri.arpa.» требует разработки политики и процедур регистрации, а также операций по поддержке этих зон DNS. Эта политика и процедуры описаны в документе Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures (RFC 3405) [5]. Обеспечение работы и администрирование этих зон накладывает ответственность на агентство IANA.

Для регистрации значений полей Services и Flags требуется одобрение IESG и публикация RFC со статусом Informational или Standards track.

Правила регистрации для URI описаны в документе RFC 2717 [17], а правила регистрации URN NID – в RFC 2611 [16].

8. Вопросы безопасности

Использование «urn.arpa.» и «uri.arpa.» в качестве реестров для пространства имен может быть объектом DoS-атак и других атак DNS spoofing. В настоящее время изучается вопрос взаимодействия с DNSSEC. Предполагается, что записи NAPTR будут подписываться ключом SIG при развертывании системы DNSSEC.

Правила перезаписи делают идентификаторы из других пространств имен объектами тех же атак, которым подвержены доменные имена. Поскольку такие атаки не удавалось легко реализовать раньше их можно рассматривать или не рассматривать как проблему.

Корректность регулярных выражений требует более серьезной проверки, нежели простая передача во что-то типа PERL.

В этом документе обсуждается способ нахождения трансляторов, но не рассматриваются какие-либо детали взаимодействия с найденным транслятором. При взаимодействии с преобразователями может возникать множество вопросов, связанных с безопасностью, но рассмотрение этих вопросов выходит за пределы данной спецификации и должно включаться в спецификации соответствующих протоколов взаимодействия с трансляторами.

9. Благодарности

Редавторы выражают свою благодарность Keith Moore за консультации в процессе подготовки этого документа. Мы благодарим также Paul Vixie за помощь при отладке реализации и ответы на наши вопросы. В заключение мы хотим поблагодарить участников конференции в Knoxville, а также членов рабочих групп URI и URN.

Специально хотим отметить Ron Daniel, котрый был соавтором исходного варианта этого документа. Его реализации и ясность мыслей внесли неоценимый вклад в прояснение множества вопросов.

Литература

[1] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS», RFC 3401, October 2002.

[2] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.

[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[4] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application», RFC 3404, October 2002.

[5] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures», RFC 3405, October 2002.

[6] Sollins, K. and L. Masinter, «Functional Requirements for Uniform Resource Names», RFC 1737, December 1994.

[7] Arms, B., «The URN Implementors, Uniform Resource Names: A Progress Report», D-Lib Magazine, February 1996.

[8] Moats, R., «URN Syntax», RFC 2141, May 1997.

[9] Gulbrandsen, A., Vixie, P. and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

[10] Daniel, R., «A Trivial Convention for using HTTP in URN Resolution», RFC 2169, June 1997.

[11] Mealling, M., «URI Resolution Services Necessary for URN Resolution», RFC 2483, January 1999.

[12] Moore, K., Browne, S., Cox, J. and J. Gettler, «Resource Cataloging and Distribution System», Technical Report CS-97-346, December 1996.

[13] Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, January 1998.

[14] Daniel, R. and M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, June 1997.

[15] Berners-Lee, T., Fielding, R. and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396, August 1998.

[16] Daigle, L., van Gulik, D., Iannella, R. and P. Falstrom, «URN Namespace Definition Mechanisms», RFC 2611, BCP 33, June 1999.

[17] Petke, R. and I. King, «Registration Procedures for URL Scheme Names», RFC 2717, BCP 35, November 1999.

[18] Mealling, M. and R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, August 2000.

Приложение A. Псевдокод

В помощь разработчикам ниже приводится псевдокод клиентской программы, использующей записи NAPTR. Этот код не задает стандартного способа обработки записей NAPTR. Кроме того, как всякий псевдокод, он не может быть выполнен непосредственно и не исключена возможность наличия в нем логических ошибок. Мы вас предупредили.

//
// findResolver(URN)
// По данному значению URN найдем хост, который может преобразовать это значение.
//
findResolver(string URN) {
   // добавляем префикс к ".urn.arpa."
   sprintf(key, "%s.urn.arpa.", extractNS(URN));
   do {
      rewrite_flag = false;
      terminal = false;
      if (key has been seen) {
         завершаем цикл при обнаружении ошибки
      }
      добавляем ключ key к списку значений seen
      records = lookup(type=NAPTR, key); // получаем все записи NAPTR RR для ключа key

      отбрасываем все записи с неизвестным значением поля flags.
      сортируем записи NAPTR по значениям полей orderи preference
         (сначала по order, а потом по preference).
      n_naptrs = число записей NAPTR в отклике.
      curr_order = records[0].order;
      max_order = records[n_naptrs-1].order;

      // обработка текущего пакета записей NAPTR в соответствии со значением поля order.
      for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
         if (unknown_flag) // пропускаем запись и переходим к следующей
            continue;
         newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
         if (!newkey) // переходим к следующей записи если перезаписи не происходит
            match continue;
         // мы не делаем перезаписи и усекаем max_order до текущего значения,
         // следовательно передача полномочий работает корректно
         max_order = naptr[j].order;
         // Если неизвестно, что делать с протоколом и службами
         // из записи NAPTR, пытаемся работать со следующей записью.
         if(!isKnownProto(naptr[j].services)) {
            continue;
         }
         if(!isKnownService(naptr[j].services)) {
            continue;

         // К этому моменту перезапись успешно завершена и мы знаем, как сделать запрос к
         // известной службе преобразования. Перед следующим просмотром проверяются флаги
         // для определения дальнейших действий.
         // Примечание: эту часть можно переписать так, чтобы корректная запись помечалась
         // и процесс продолжался с целью поиска “лучшей” записи.
         // Однако этот код достаточно велик, а наше приложение является лишь иллюстрацией.
         if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) {
            terminal = true;
            services = naptr[j].services;
            addnl = все записи SRV и/или A, возвращенные как дополнение к naptr[j].
         }
         key = newkey;
         rewriteflag = true;
         break;
      }
   } while (rewriteflag && !terminal); 

   // Путь к преобразователю найден?
   if (!rewrite_flag) {
      сообщить об ошибке;
      return NULL;
   }

   // Оставить дальнейшее другому протоколу?
   if (strcasecmp(flags, "P")) {
      возвратить ключ key, как хост для обращения;
   } 

   // если нет, продолжаем
   if (!addnl) { // В дополнительной информации нет записей SRV, ищем их
      srvs = lookup(type=SRV, key);
   }

   сортируем записи SRV по полям preference, weight, ...
   for each (SRV record) { // в порядке значений preference
      пытаемся соединиться с srv[j].target, используя протокол и одну из служб преобразования,
      в поле services последней записи NAPTR.
      if (successful)
         return (target, protocol, service);
         // Возможно, мы будем в реальности возвращать результат, но этот код предполагает,
         // что просто найден хороший хост для ссоединения с ним.
   }
   завершение с ошибкой "не удалось найти хост”;
}

Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

US

EMail: michael@neonym.net

URI: http://www.verisignlabs.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Uniform Resource Identifiers – однотипные идентификаторы ресурсов.

2Dynamic Delegation Discovery System – динамическая система детектирования передачи полномочий (делегирования).

3Uniform Resource Names – однотипные имена ресурсов.

4Domain Name System – система доменных имен

5Naming Authority Pointer — указатель на уполномоченный сервер именования

6Application Unique String – уникальная строка приложения

7В оригинале ошибочно дается ссылка на RFC 3404. Прим. перев.

8Resource Cataloging and Distribution Service — служба каталогизации и распространения.

9В оригинале ошибочно дается ссылка на RFC 3404. Прим. перев.




RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database

Network Working Group                                    M. Mealling
Request for Comments: 3403                                  VeriSign
Obsoletes: 2915, 2168                                   October 2002
Category: Standards Track

Система DDDS. Часть 3 – База данных DNS

Dynamic Delegation Discovery System (DDDS)

Part Three: The Domain Name System (DNS) Database

PDF

Статус документа

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

Этот документ описывает Базу данных DDDS1, использующую систему DNS2 в качестве распределенной базы Правил. Ключами являются доменные имена и Правила представляются с использованием записей NAPTR RR3.

Поскольку этот документ отменяет действие RFC 2915, он является официальной спецификацией для записей NAPTR в DNS. Документ также является частью серии, полностью указанной в документе Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401). Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Оглавление

Исключено из версии HTML

1. Введение

Система DDDS обеспечивает возможность организации связей между строками данных для поддержки систем передачи полномочий (делегирования0 с динамической конфигурацией. Работа DDDS основана на отображении некой уникальной строки на данные, хранящиеся в Базе данных DDDS путем итеративного применения правил преобразования строк до выполнения условий завершения.

Этот документ описывает способ, при котором используется система DNS в качестве хранилища Правил, обеспечивающих функционирование Приложения DDDS. Документ не задает какого-либо конкретного приложения или сценария использования. Вся серия документов описана в Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) [1]. Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Описанная здесь запись DNS NAPTR была изначально предложена рабочей группой URN в качестве способа представления наборов правил в DNS, позволяющих разобрать делегированную часть URI4 таким образом, чтобы она могла быть изменена и ределегирована с течением времени. В результате получились записи RR5, включающие регулярные выражения, которые используются клиентскими программами для преобразования строк в доменные имена.

Регулярные выражения были выбраны за их возможность компактно выражать большие объемы информации для передачи в обычно небольших пакетах DNS.

Со временем процесс был обобщен для других Приложений и Баз данных о Правилах. В этом документе определена База данных о Правилах без задания какого-либо Приложения, поскольку может существовать множество Приложений, способных использовать эту Базу данных о Правилах.

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [6].

Все прочие термины, особенно выделенные шрифтом, заимствованы из [3].

3. Спецификация Базы данных DDDS

General Description — общее описание

Эта база данных использует систему DNS, описанную в [8] и [7].

Набором символов, используемых для задания различных значений записей NAPTR является UTF-8 [17]. Следует соблюдать осторожность в тех случаях, когда ввод или вывод выражений для замены содержит коды, выходящие за пределы эквивалентности ASCII/Unicode в UTF-8 – любые символы UTF-8 интерпретируются как последовательности кодовых точек (code-point), а не байтов. Это сделано для поддержки других языков в расширенных регулярных выражениях POSIX6, чтобы обеспечить возможность соответствия предназначенным кодовым точкам. Недопустимо писать выражения для замены так, чтобы они зависели от локальных установок POSIX7, поскольку это приведет к потере выражениями для замены их универсальности в применении.

Все записи о ресурсах DNS имеют связанное с ними значение времени жизни TTL8. По истечении с момента отыскания записи соответствующего числа секунд корректность записи теряется и нужно сделать новый запрос для получения новых записей. Таким образом, как указано в Алгоритме DDDS, могут возникать ситуации, когда срок действия данного Правила истекает. В тех случаях, когда приложение пытается вернуться к ранее найденным наборам Правил (в случае неподходящего пути передачи полномочий или при отказе сервера) приложение должно обеспечить гарантию того, что ни одна из записей, к которым происходит возврат, не перестала быть корректной по времени жизни. Если истек срок действия хотя бы одной записи приложение должно вернуть процесс на первый шаг алгоритма.

Key Format – формат ключей

Ключ представляет собой корректно сформированное доменное имя DNS.

Lookup Request – поисковый запрос

Чтобы запросить набор правил для данного Ключа, клиент вводит запрос, соответствующий стандартным правилам DNS, для записис NAPTR RR, соответствующей данному доменному имени.

Lookup Response – отклик при поиске

Отклик на запрос для данного Ключа (доменное имя) будет серией записей NAPTR. Формат записи NAPTR описан в главе 4.

Rule Insertion Procedure — процедура вставки правил

Правила вставляются путем добавления новых записей в соответствующую зону DNS. Если Правило производит Ключ, который существует в конкретной зоне, тогда только объект, имеющий административный контроль над этой зоной, может задавать Правило, связанное с таким Ключом.

Collision Avoidance – предотвращение конфликтов

В том случае, когда два Приложения могут использовать эту Базу данных (на практике это случай использования базы приложениями ENUM и URI Resolution, описанный в параграфе 6.2), возможно возникновение конфликта между правилами, когда в домене появляются две записи NAPTR, применимые более, чем к одному Приложению. Существуют три способа предотвращения конфликтов.

  • Создание в домене новой зоны, которая содержит только записи NAPTR, которые подходят для Приложения. Например, все записи URI Resolution могут размещаться в зоне urires.example.com, а все записи ENUM – в зоне enum.example.com. В том случае, когда такое решение невозможно по причине отсутствия контроля над восходящим делегированием9, следует использовать второй метод.

  • Создание регулярного выражения, содержащего часть строки AUS10, достаточную для однозначной идентификации приложения. Например, URI Resolution может использовать имя схемы слева для привязки регулярного выражения к соответствию этой схеме. Связанные с ENUM записи в той же зоне могут привязываться слева к соответствию символу «+», который определен в ENUM как начало каждой строки AUS. В результате данной строке AUS может соответствовать лишь одна из записей, а не две.
  • Если два приложения используют различные значения Flags или Services, тогда записи другого Приложения можно игнорировать, поскольку они не будут соответствовать значению Services/Flags.

4. Формат NAPTR RR

4.1 Формат пакета

Формат пакетов NAPTR RR показан на рисунке. Код типа DNS для NAPTR имеет значение 35.

                                       1  1  1  1  1  1
         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                     ORDER                     |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                   PREFERENCE                  |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                     FLAGS                     /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                   SERVICES                    /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                    REGEXP                     /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                  REPLACEMENT                  /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Определения <character-string> (строка символов) и <domain-name> (доменное имя) приведены в RFC 1035 [7].

ORDER

16-битовое целое число без знака, задающее порядок, в котором должны обрабатываться записи NAPTR для точного представления упорядоченного списка Правил. Упорядочивание идет от меньших значений к большим. Если две записи имеют одинаковое значение порядка, считается, что они являются одним правилом и выбор следует делать на основе комбинации значений Preference и Services

PREFERENCE

Хотя это поле и носит название «предпочтение» в соответствии с принятой в DNS терминологией, в Алгоритме DDDS оно является эквивалентом значения Priority. Это 16-битовое целое число без знака, которое задает порядок, в котором следует обрабатывать записи NAPTR с одинаковыми значениями поля Order (младшие номера обрабатываются раньше старших). Это похоже на поле Preference в записи MX и используется так, чтобы администратор домена мог направить клиентов на более подходящие хосты или менее отягощенные протоколы. Клиент может обращаться к записям с более высокими значениями поля Preference, если у клиента есть достаточные основания для этого (например, отсутствие поддержки некоторых протоколов или служб).

Важное различие между полями Order и Preference заключается в том, что после того, как найдено соответствие, для клиента недопустимо обращаться к записям с другими значениями поля Order, но можно обрабатывать записи с одинаковыми значениями Order и различными значениями Preferences. Единственное исключение из этого правила указано в Примечании к спецификации алгоритма DDDS по части разрешения клиенту использовать более сложное определение сервиса между п. 3 и п. 4 в алгоритме. Значение Preference используется для обозначения более высокого качества сервиса в правилах, которые рассматриваются как одинаковые с точки зрения передачи полномочий, но не с точки зрения распределения нагрузки.

Важно отметить, что DNS поддерживает несколько механизмов распределения нагрузки и если распределение нагрузки требуется как сервис, для распределения нагрузки следует использовать такие средства, как записи SRV или множественные записи типа A.

FLAGS

Строка символов (<character-string>), содержащая флаги для контроля деталей перезаписи и интерпретации полей записи. Флаги представляют собой одиночные буквы от A до Z или цифры от 0 до 9. регистр букв во внимание не принимается. Поле флагов может быть пустым.

Приложение само задает, как оно использует эту Базу данных для определения флагов в этом поле. Приложение должно определить, какие из флагов трактуются как завершающие.

SERVICES

Строка символов (<character-string>), задающая Параметры сервиса (Service Parameters), применимые к данному пути передачи полномочий. Значения этого поля определяются спецификацией Приложения.

REGEXP

Строка символов (<character-string>), содержащая выражение для замены, которое применяется к исходной строке, сохраняемой клиентом для конструирования следующего искомого доменного имени. Синтаксис этого поля описан в спецификации Алгоритма DDDS.

Как указано в алгоритме DDDS, регулярные выражения недопустимо использовать в кумулятивной манере – они должны применяться исключительно к исходной строке, сохраняемой клиентом, а не к доменным именам, созданным предыдущей перезаписью NAPTR. Второй вариант представляется заманчивым для некоторых приложений, но опыт показывает что такой вариант подвержен отказам, склонен к возникновению ошибок и очень сложен в отладке.

REPLACEMENT

Строка <domain-name>, которая является следующим доменным именем для запроса в зависимости от возможных значений поля флагов. Это поле используется в тех случаях, когда регулярное выражение представляет собой простую операцию замены. Любое значение в этом поле должно быть полным доменным именем. Сокращение имен для этого поля не применяется.

Это поле вместе с полем REGEXP создают Выражение для замены11 в Алгоритме DDDS. Существование этого поля обусловлено историческими причинами, связанными с возможностью сокращения имен в DNS. Упомянутые поля являются взаимоисключающими. Если возвращена запись, имеющая значения для обоих полей, это рассматривается как ошибка и следует игнорировать результат или возвращать сообщение об ошибке.

4.2 Обработка дополнительной информации

Обработка раздела Additional требует обновленных серверов DNS, поэтому пройдет много лет прежде, чем предложения смогут столкнуться с имеющими отношение к делу записями в разделе дополнительной информации.

4.2.1 Обработка раздела Additional Information серверами DNS

Серверы DNS могут добавлять в раздел дополнительной информации наборы RRset, имеющие отношение к ответу и такой же уровень аутентичности, что и данные в разделе Answer. В общем случае это могут быть записи A и SRV, в зависимости от приложения.

4.2.2 Обработка Additional Information преобразователями и приложениями

Приложения могут проверять раздел Additional Information на предмет наличия имеющих отношение к делу записей, но для Приложений недопустимо требовать наличия каких-либо записей в разделе Additional Information любого отклика DNS для обеспечения возможности работы клиентов. Все Приложения должны быть способны обрабатывать отклики от серверов имен, которые никогда не заполняют в откликах раздел Additional Information.

4.3 Формат Master-файла

Формат master-файла соответствует стандартным правилам RFC 1035. Поля Order и Preference, будучи 16-битовыми целыми числами без знака, могут принимать значения от 0 до 65535. Поля Flags, Services и Regexp являются заключенными в кавычки строками (<character-string>). Поскольку поле Regexp может содержать множество символов обратной дробной черты ((backslash), это поле следует трактовать с осторожностью. Работа с регулярными выражениями рассмотрена в главе 7.

5. Спецификация Приложения

Эта База данных DDDS применима для любых приложений, использующих алгоритм DDDS. В дополнение к элементам, требуемым для спецификации Приложения DDDS, приложения, желающие использовать эту базу данных, должны определить перечисленные ниже значения.

  • К какому домену относится Ключ, создаваемый правилом First Well Known Rule. Каждое приложение должно обеспечивать гарантию того, что его правила не будут конфликтовать с правилами, используемыми другими приложениями, которые работают в этой же Базой данных. Например, приложение foo может задать, что все его ключи, создаваемые первым общеизвестным правилом будут относиться к зоне foo.net.
  • Какие значения допустимы в полях Services и Protocols.
  • Каким предполагается вывод завершающего правила перезаписи в дополнение к способу реального представления и использования флагов.

6. Примеры

6.1 Пример URN

Записи NAPTR изначально создавались для использования с сервисом URN RDS12 [15]. В этом примере рассматривается, как конкретное имя URN будет использовать запись NAPTR для поиска преобразователя, который может ответить на вопрос о URN. Спецификация этого Приложения приведена в документе [2].

Рассмотрим пространство имен a URN, основанное на MIME Content-Id (гипотетическое пространство). URN может иметь вид:

urn:cid:199606121851.1@bar.example.com

Первое общеизвестное правило Приложения служит для извлечения символов между первым и вторым двоеточием. В нашем примере это будет cid. Приложение также задает, что для построения корректного Ключа в конце результата работы First Well Known Rule следует добавить строку urn.arpa. Окончательным результатом тогда будет служить cid.urn.arpa. Далее клиент запрашивает в DNS записи NAPTR для доменного имени cid.urn.arpa. Результатом будет единственная запись:

cid.urn.arpa.
  ;; order pref flags service regexp replacement
  IN NAPTR   100   10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i"  .

Поскольку запись является единственной в отклике, проблемы упорядочения не возникает. Поле замены пусто, поэтому используется шаблон, возвращенный в поле regexp. Применим выражение regexp ко всему значению URN для проверки наличия соответствия. Последовательность выражения для замены \2 возвращает подстроку example.com. Поскольку поле флагов пусто, поиск не является завершающим и наш следующий запрос к DNS возвратит большее число записей NAPTR, где новое доменное имя example.com.

Отметим, что правило не выделяет полное доменное имя из CID, предполагая вместо этого, что CID происходит от хоста и выделяется домен для этого хоста. Когда все хосты (такие, как bar) могут иметь свои записи NAPTR, поддержка таких записей для всех машин сайта может стать чересчур обременительной. Шаблоны здесь не подойдут, поскольку они возвращают результат только в тех случаях, когда в системе отсутствует точное соответствие для имен.

Запись, возвращенная для запроса example.com может иметь вид:

example.com.
   ;; order pref flags service regexp replacement
   IN NAPTR 100 50 "a" "z3950+N2L+N2C" ""     cidserver.example.com.
   IN NAPTR 100 50 "a" "rcds+N2C" ""          cidserver.example.com.
   IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" ""  www.example.com.

Продолжая этот пример, отметим, что значения полей Order и Preference равны для всех записей, поэтому клиент может выбрать любую запись. Приложение определяет, что флаг ‘a’ указывает на завершение поиска и выводом перезаписи будет доменное имя, для которого следует запросить запись типа A. Когда клиент сделает это, он узнает хост, его IP-адрес, протокол и доступные для этого протокола службы. Этой информации клиенту достаточно для контакта с сервером и передачи тому запроса о URN.

Повторно используем регулярное выражения, содержащее \2, для выделения доменного имени из CID и \. для соответствия символу ‘.’, разделяющему компоненты доменного имени. Поскольку \ является escape-символом, включение самого этого символа должно использовать предшествующий ему дополнительный символ \ (escape). Для случая приведенной выше записис cid.urn.arpa регулярное выражение в master-файле должно иметь вид «!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i». Когда клиент получит реальную запись, та будет преобразована к виду «!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i».

6.2 Пример E164

Рабочая группа ENUM подготовила спецификацию сервиса, который позволяет отображать телефонные номера на URI [18]. Строка AUS для Приложения ENUM представляет собой телефонный номер E.164 с удаленными символами “-”. Первое общеизвестное правило обеспечивает удаление из телефонного номера ненужные символы13 и полученное в результате значение используется как первый Ключ. Например, телефонный номер 770-555-121214 в формате E.164 будет иметь вид +1-770-555-1212. Полученный в результате преобразования первый Ключ будет иметь значение 17705551212.

В настоящее время ENUM является единственным приложением, использующим эту Базу данных. Спецификация приложения задает для преобразования первого Ключа в формат, корректный для Базы данных вставку точек между цифрами и добавления строки “e164.arpa.” в конце. Для упомянутого выше телефонного номера преобразованный ключ будет иметь значение “2.1.2.1.5.5.5.0.7.7.1.e164.arpa.”. Это доменное имя используется для нахождения Правил перезаписи, как записей NAPTR.

Для нашего примера мы можем получить в результате следующие записи NAPTR:

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" .
IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .

Оба приложения ENUM [18] и URI Resolution [4] используют флаг ‘u’. Это флаг говорит, что Правило является завершающим и результатом служит значение URI, которое содержит информацию, требуемую для обращения в телефонную компанию. ENUM также использует такой формат для своих параметров сервиса (Service Parameters). Это показывает, что для доступа к телефонному сервису поддерживается протокол Session Initiation Protocol или SMTP (электронная почта).

7. Совет администраторам DNS

Остерегайтесь регулярных выражений. Они не только достаточно сложны сами по себе, но ещ и взаимодействуют с DNS, как было отмечено выше. Любые символы обратной дробной черты (\) в регулярном выражении должны указываться дважды, чтобы в отклике на запрос появился одиночный символ \. Более того, использование двойных символов \ возможно не было протестировано со всеми реализациями серверов DNS.

Чтобы не возникало ненужных проблем с файлами зон, администраторам рекомендуется использовать при написании правил перезаписи свойство регулярных выражений default delimiter15. По спецификации DDDS регулярные выражения начинаются с символа, который будет использоваться в качестве ограничителя. Следовательно, если первым символом регулярного выражения является восклицательный знак (например), регулярное выражение можно создать с использованием меньшего числа символов \.

8. Примечания

Клиент должен обрабатывать множество записей NAPTR, упорядоченных по значению поля Order, и недопустимо просто использовать первую запись, которая обеспечивает известную комбинацию Service Parameter.

Если множество записей RR имеют одинаковое значение поля Order и все прочие критерии дают одинаковый результат, клиенту следует использовать значение поля Preference для выбора следующей рассматриваемой записи NAPTR. Однако, поскольку во многих случаях существуют предпочтительные протоколы или службы, клиент может использовать для сортировки записей иные критерии.

При отказе после перезаписи клиенту настоятельно рекомендуется сообщить об отказе, а не просто переходить к использованию других путей перезаписи.

9. Согласование с IANA

Значения полей Services и Flags будут определяться Приложением, использующим эту Базу данных DDDS. Это может потребовать механизма регистрации и связанных с такой регистрацией ресурсов IANA. Данная спецификация таких требований не включает.

10. Вопросы безопасности

Записи NAPTR, подобно всем прочим записям DNS, могут подписываться и проверяться в соответствии с процедурами DNSSEC.

Эта База данных делает идентификаторы из других пространств имен объектами тех же атак, которым подвержены обычные доменные имена. Поскольку этот вопрос не был разрешен ранее, он может рассматриваться (или не рассматриваться) как проблемы.

Следует проверять корректность регулярных выражений, не просто передавая из чему-либо типа PERL, поскольку в такие выражения может быть включен произвольный код, который будет выполнен в системе.

Литература

[1] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS», RFC 3401, October 2002.

[2] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.

[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[4] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application», RFC 3404, October 2002.

[5] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures», RFC 3405, October 2002.

[6] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[7] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[8] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[9] Gulbrandsen, A., Vixie, P. and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

[10] Crocker, D., «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[11] Daniel, R., «A Trivial Convention for using HTTP in URN Resolution», RFC 2169, June 1997.

[12] IEEE, «IEEE Standard for Information Technology – Portable Operating System Interface (POSIX) — Part 2: Shell and Utilities (Vol. 1)», IEEE Std 1003.2-1992, January 1993.

[13] Berners-Lee, T., Fielding, R. and L. Masinter, «Uniform Resource Identifiers (URI): Generic Syntax», RFC 2396, August 1998.

[14] Moats, R., «URN Syntax», RFC 2141, May 1997.

[15] Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, January 1998.

[16] Daniel, R. and M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, June 1997.

[17] Yergeau, F., «UTF-8, a transformation format of ISO 10646», RFC 2279, January 1998.с

[18] Faltstrom, P., «E.164 number and DNS», RFC 2916, September 2000.

Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

US

EMail: michael@neonym.net

URI: http://www.verisignlabs.com

Полное заявление авторский прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Dynamic Delegation Discovery System – динамическая система детектирования передачи полномочий.

2Domain Name System – система доменных имен

3Naming Authority Pointer Resource Record – запись для указателя на уполномоченный сервер именования.

4Uniform Resource Identifiers – однотипные идентификаторы ресурсов.

5Resource Record – запись о ресурсах.

6POSIX Extended Regular Expression

7POSIX locale

8Time To Live

9В оригинале “upstream delegation” — передача полномочий вверх по иерархии. Прим. перев.

10Application Unique String – уникальная строка приложения

11Substitution Expression

12Uniform Resource Name Resolver Discovery Service — служба обнаружения преобразователей однотипных имен ресурсов.

13Все символы, за исключением цифр. Прим. перев.

14Номер телефона в США. Прим. перев.

15Используемый по умолчанию ограничитель.




RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm

Network Working Group                                    M. Mealling
Request for Comments: 3402                                  Verisign
Obsoletes: 2915, 2168                                   October 2002
Category: Standards Track

 

Система DDDS. Часть 2 — Алгоритм

Dynamic Delegation Discovery System (DDDS)

Part Two: The Algorithm

PDF

Статус документа

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

Этот документ описывает алгоритм DDDS1) для применения динамически отыскиваемых правил преобразования строк по отношению уникальным строкам приложений. Четко определенные правила преобразования будут отражать передачу полномочий управления информацией, связанной со строкой. Этот документ является частью серии документов, полностью указанной в Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401). Важно отметить, что чтение и понимание каждого документа этой серии невозможно без прочтения остальных документов.

Оглавление

Исключено из версии HTML.

1. Введение

Система DDDS используется для реализации простого связывания строк с данными, обеспечивающего поддержку динамически настраиваемых систем передачи полномочий (делегирования). DDDS отображает некие уникальные строки на данные, хранящиеся в DDDS Database2, путем итеративного применения правил преобразования строк, пока не будут достигнуты условия завершения.

Этот документ описывает общий алгоритм DDDS, а не какие-либо частные алгоритмы или сценарии использования. Вся серия документов указана в Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) [1]. Важно отметить, что чтение и понимание каждого документа этой серии невозможно без прочтения остальных документов.

История DDDS включает процесс, начавшийся с работы группы Uniform Resource Name. Когда были изначально сформулированы имена URN3 [6], было принято решение определить полномочный сервер для URN так, чтобы (конструктивно) там не содержалось информации о местоположении в сети. Система может использовать базу данных с правилами, которые будут применяться к URN для отыскания информации о конкретных синтаксических блоках4. Эта система изначально получила название RDS5 [7] и применялась только по отношению к URN.

С течением времени множество систем начало использовать такой же алгоритм и инфраструктуру для других, не связанных с URN, систем (см. примеры использования DDDS в главе 6). Это привело к необходимости изменения и разъяснения некоторых основополагающих допущений. Этот набор документов служит обновлением для исходных спецификаций URN, позволяющим разрабатывать новые приложения и базы правил стандартным способом.

Этот документ отменяет RFC 2168 [11] и RFC 2915 [9], а также обновляет RFC 2276 [7].

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119.

Application Unique String – Уникальная строка Приложения

Строка, являющаяся начальными данными для приложения DDDS. Лексическая структура этой строки должна заключать в себе уникальный путь делегирования, который анализируется и трассируется повторяющимся выбором и применением правил перезаписи (Rewrite Rule).

Rewrite Rule – правило перезаписи

Правило, которое применяется к Application Unique String для создания нового ключа выбора нового правила перезаписи из базы правил или результирующей строки, которая возвращается вызвавшему приложению. Часто используется просто термин Правило (Rule).

First Well Known Rule – первое общеизвестное правило

Это правило перезаписи, которое определяется приложением и реально не хранится в базе правил (Rule Database). Это праило используется для создания первого корректного ключа.

Terminal Rule – конечное правило

Правило перезаписи, при использовании которого возвращается строка конечного результата процесса DDDS, а не другой ключ базы данных.

Application — Приложение

Набор протоколов и спецификаций, которые задают реальные значения для различных обобщенных частей алгоритма DDDS. Приложение должно определять синтаксис и семантику Application Unique String, First Well Known Rule и одной или множества баз данных, которые корректны для этого Приложения.

Rule Database – База правил

Любое хранилище правил, позволяющее по уникальному ключу идентифицировать набор правил, задающих этап передачи полномочий используемый для конкретного значения ключа (Key).

Services — службы

Общая база правил может использоваться для связывания различных служб с данной строкой Application Unique String (например, различные функции протокола, разные рабочие характеристики, географическое положение, обратная совместимость и т. п.). Возможными вариантами служб могут быть, например, получение сообщения по факсу/телефону/электронной почте, распределение нагрузки между web-серверами, выбор ближайшего сервера-зеркала, учет отношения цена/производительность и т. п. Эти Службы включаются как часть Правила, чтобы позволить Приложению принять решение о выборе на основе применимости той или иной ветви процесса или иных параметров Сервиса.

Flags — флаги

Большинство Приложений будет требовать для Правил способа сигнализировать Приложению, что некие Правила обеспечивают варианты результата6 (например, различные форматы вывода, механизмы расширяемости, сигнализация конечного правила и т. п.), тогда, как другие правила этого не делают. Большинство Баз данных определяют поле Flags, которое Приложение может использовать для представления различных значений, выражаемых этими сигналами.

3. Алгоритм

Алгоритм DDDS основан на концепции Правил перезаписи (Rewrite Rule). Эти правила собираются в базу DDDS Rule Database, и доступ к ним обеспечивается по уникальным ключам. Конкретное Правило, будучи примененным к Application Unique String, преобразует эту строку в новый Ключ, который может использоваться для отыскания нового Правила в Базе. Это новое правило применяется к исходной строке Application Unique String и цикл повторяется, пока не будет выполнено условие завершения. Приложению недопустимо применять правило для вывода предыдущего правила. Все Правила перезаписи для всех Приложений должны всегда применяться точно к той же строке Application Unique String, с которой алгоритм начал работу.

Фундаментальны допущением является то, что строка Application Unique String представляет собой некий тип регулярной лексической структуры, к которой применяются правила. DDDS предполагает, что лексический элемент, используемый для принятия решения о передаче полномочий, содержится в самой строке Application Unique String. DDDS не решает задачи, когда для принятия решения о делегировании требуется информация, содержащаяся за пределами строки AUS и Правила (время сутом, финансовые транзакции и т. п..).

Схема работы алгоритма показана на рисунке.

+-------- Application Unique String
|                +----+
|                |ввод|
|        +-------+    +----------+
|        | First Well Known Rule |
|        +-------+     +---------+
|                |вывод|
|                +-----+
|              Первый ключ
|                   |
|                   +----<--------------<--------------+
|                   |                                  |
|                 ключ (База данных DDDS всегда        |
|                +----+ принимает ключ и               |
|                |ввод| возвращает правило)            ^
|      +---------+    +--------+                       |
|      | Поиск в DDDS Database |                       |
|      +---------+     +-------+                       |
|                |вывод|                               |
|                +-----+                               |
|             Набор правил                             |
|                   |                                  |
|                   |      (вводом для правила служит  |
|             Набор правил  правило и AUS.             ^
|                +----+     Выводом всегда служит      |
+--------------->|ввод|     ключ или результат)        |
  +--------------+    +--------------------+           |
  | Правила применяются к AUS,             |           |
  | пока не будет получен результат,       |           |
  | удовлетворяющий требованиям приложения |           |
  +---------------+     +------------------+           |
                  |вывод|                              |
                  +-----+                              ^
                   ключ                                |
                    |                                  |
                    v                                  |
     +-------------------------------------+           |
     | Последнее правило было завершающим? | Нет >-----+
     +-------------------------------------+
                    Да (если правило не является завершающим,
                    |   его вывод служит новым ключом
                    |   для поиска следующего правила)
   +-----------------------------------+
   | Вывод последнего правила является |
   | результатом для приложения        |
   +-----------------------------------+

3.1 Компоненты правила

Правил содержит до 4 компонент:

Приоритет

Число, которое определяет приоритет в случае выбора из двух правил, совпадающих в остальном. Это позволяет включать в базу данных правила, которые дают похожие результаты, но один из путей делегирования может быть быстрее, лучше или дешевле, чем другой.

Набор флагов

Флаги служат для задания атрибутов правила, которые определяют, является ли это правило последним из числа применяемых. Последнее правило называется завершающим (terminal rule) и его вывод служит результатом для приложения. Флаги являются уникальными для Приложений. Приложение может указать, что оно использует флаг, определенный другим Приложением, но в этом случае должно использоваться заданное тем Приложением определение. Одно Приложение не может переопределить Флаг, заданный другим Приложением. Это означает, что в будущем может потребоваться реестр флагов, но в настоящее время такое требование отсутствует.

Описание сервиса

Описание сервиса используется для указания семантических атрибутов определенной ветви передачи полномочий. Существует множество случаев, когда две ветви идентичны за исключением того, что одна ведет к результату, обеспечивающему один набор функций, в вторая – к результату с другим набором. Эти функции могут включать эксплуатационные параметры типа распределения нагрузки, разделения трафика по географическим признакам, совместимости со старыми версиями и т. п. Например, два правила могут быть одинаково применимы к конкретному решению о делегировании для строки. Одно правило может вести к заключительному правилу, которое обеспечивает информацию для использования в среде с высоким уровнем доступности, а другое — к архивной службе, которая работает более медленно, но более стабильна во времени.

Выражение для замены

Эта часть правила задает изменение строки и представляет собой комбинацию расширенного регулярного выражения7 POSIX [8] и строки замены (подобно выражениям для замены в Unix-редакторе sed).

3.2 Синтаксис выражения для замены

Набор (наборы) символов, используемый в выражениях для замены, определяется как Приложением, так и Базой данных. Приложение должно определить допустимый набор символов для строки AUS. Спецификация DDDS Database должна определить, какие наборы символов требуются для создания ключей и как представляется само выражение для замены. Приведенные ниже символы имеют смысл лишь при выборе определенного набора символов в базе данных и/или Приложении.

Синтаксис Выражения для замены в правилах представляет собой выражение в стиле редактора sed. Сами по себе выражения в стиле sed не подходят для использования в приложениях по ряду причин., следовательно, содержимое поля regexp должно соответствовать приведенным ниже правилам.

subst-expr   = delim-char ere delim-char repl delim-char *flags
delim-char   = "/" / "!" / <любой октет, отсутствующий в полях POS-DIGIT и flags>
               ; Все вхождения delim_char в subst_expr должны быть одинаковы
ere          = <POSIX Extended Regular Expression>
repl         = *(string / backref)
string       = *(anychar / escapeddelim)
anychar      = <любой символ, отличный от delim-char>
escapeddelim = "\" delim-char
backref      = "\" POS-DIGIT
flags        = "i"
POS-DIGIT    = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

Применение выражения для замены к Строке должно давать в результате ключ, который соответствует правилам базы данных (естественно, если текущий ключ не является завершающим, при котором возвращается не новый ключ, а окончательный результат). Поскольку имеется возможность некорректно задать регулярное выражение, что будет приводить к созданию неприемлемого ключа, клиентской программе следует убедиться, что результат является корректным ключом базы данных, прежде, чем использовать этот ключ.

Выражения backref в repl-части выражения для замены меняются на строку (возможно пустую) символов, заключенных в круглые скобки () в ERE-части выражения для замены. N представляет собой одиночную цифру от 1 до 9, включительно. Эта цифра задает N-ое выражение backref, которое начинается с N-ой скобки ( и продолжается до соответствующей скобки ). Например, ERE

(A(B(C)DE)(F)G)

имеет backref-выражения:

\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 = ошибка – нет соответствующего субвыражения

Флаг i показывает, что соответствие ERE следует проверять без учета регистра символов. Более того, любые backref-подстановки могут быть нормализованы к нижнему регистру при наличии флага i. Этот флаг имеет смысл только в тех случаях, когда Приложение и База данных определяют набор символов, в котором отказ от учета регистра символов является корректным.

Первый символ выражения для замены следует использовать, как символ-ограничитель компонент этого выражения. В выражении для замены должно быть ровно три символа-ограничителя без предшествующего escape-символа. Поскольку символы-ограничители с предшествующим символом escape будут интерпретироваться как собственно символы (не ограничители), недопустимо использовать в качестве ограничителей цифровые символы. При включении цифр будут возникать проблемы в выражениях backref. Кроме того, при наличии флагов в выражении для замены символ флага недопустимо использовать в качестве ограничителя.

3.3 Полный алгоритм

Ниже приводится алгоритм DDDS целиком.

  1. Применяется правило First Well Known Rule к строке Application Unique String и в результате возвращается ключ Key.
  2. Приложение запрашивает Базу данных для получения упорядоченного списка правил, соответствующих ключу Key8.
  3. Для каждого Правила в списке используется замена с помощью Substitution Expression, применяемая с соблюдением порядка к строке Application Unique String, пока не будет возвращена непустая строка. Положение в списке фиксируется и породившее непустую строку Правило используется для следующего шага. Если на следующем шаге выбранное правило отвергается, происходит возврат к использованию Substitution Expression для оставшейся части списка правил. Если список завершится без возврата корректно соответствия, приложение уведомляется об этом.
  4. Если Описание сервиса в правиле не соответствует требованиям клиента, происходит возврат к п. 3 и продолжение работы с оставшейся частью списка правил. Если в списке имеется правило, соответствующее требованиям клиента, это Правило используется для следующего шага. В том (и только в том) случае, когда клиент способен обработать Правило и если такая обработка представляется безопасной в соответствии со спецификацией Приложения, клиент может отметить текущее Правило и продолжить выполнение п. 3, как будто правило было отвергнуто. В любом случае результатом данного этапа является одно и только одно Правило.
  5. Если Flags в Правиле показывает, что данное правило не является завершающим (NOT Terminal), происходит возврат к п. 2 с использованием полученного результата в качестве нового Ключа.
  6. Приложение уведомляется о завершении процесса и ему передаются из Правила значения Flags и Services вместе с выводом последнего выражения Substitution Expression.

4. Спецификация Приложения

Для того, чтобы описанный алгоритм стал используемым, нужно написать спецификации приложения и по крайней мере одной базы данных. Для задания спецификации приложения требуются перечисленные ниже компоненты.

Application Unique String – Уникальная Строка Приложения

Это единственная строка, к которой применяются правила перезаписи. Строка должна иметь регулярную структуру и быть уникальной в приложении так, чтобы все, кто применяет Правила из одной Базы данных, получали в результате одинаковые Ключи. Например, приложение URI Resolution в качестве Application Unique String определяет URI.

Ни каким приложениям не дозволено определять Application Unique String так, чтобы Ключ, полученный правилом перезаписи, трактовался бы как Application Unique String для ввода в новое правило, поскольку это ведет к правилам перезаписи в стиле sendmail, которые отличаются склонностью к ошибкам. Единственное исключение из этого правила возможно в случае, когда Приложение определяет некий флаг или состояние, в котором правила для приложения подавляются и принимается новое Приложение DDDS или некий произвольный набор правил. Один из таких случаев можно найти в приложении URI Resolution, которое определяет флаг p, указывающий, что следующий шаг зависит от протокола (protocol specific) и, таким образом, выходит за рамки DDDS.

First Well Known Rule – Первое Общеизвестное Правило

Это первое правило, которое применяется к Application Unique String и создает первый Ключ. Для выражения может использоваться такая же форма, какая принята для Правил, или несколько более сложная форма. Например, приложение URI Resolution может задавать, что это правило возвращает в качестве первого Ключа последовательность символов URI вплоть (но не включая) до первого двоеточия (схема URI).

Valid Databases – корректные Базы данных

Приложение может определить, какая из Баз данных является корректной. Для каждой базы данных Приложение должно определить, как вывод правила First Well Known Rule (первый Ключ) может быть обращен во что-либо, подходящее для этой Базы данных. Например, приложение URI Resolution может использовать в качестве Базы данных систему DNS9. Операция обращения первого Ключа во что-либо, подходящее для базы данных, будет преобразованием в некое корректное с точки зрения DNS имя. В дополнение для каждой Базы данных, которую определяет Приложение, оно должно задать допустимые наборы символов, которые будут порождать корректные Ключи. В примере URI Resolution набором символов URI является 7-битовый код ASCII, который согласуется с 8-битовым ограничением для символов в файлах зон DNS.

Expected Output – ожидаемый результат

Приложение должно определить ожидаемый результат Завершающего Правила. Например, приложение URI Resolution направлено на поиск серверов, которые содержат полномочные данные о данном URI. Таким образом, результатом завершающего правила будет информация (хосты, порты, протоколы и т. п.), которая будет служить для контакта с полномочным сервером.

В прошлом были некоторые недоразумения, касающиеся распределения нагрузки и использования DDDS Priority. Приложениям следует понимать, что Priority данного правила является лишь способом показать, что одно правило “быстрее, лучше, дешевле” другого. Если приложению требуется некий метод, позволяющий клиенту распределять нагрузку между серверами (например, взвешенный случайный выбор и т. п.), это следует реализовать за пределами алгоритма DDDS. Например, Приложение, использующее DNS Database может трактовать запись SRV, как способ обозначения того, что определенная служба действительно поддерживается несколькими скооперированными хостами. Распределение нагрузки будет осуществляться между хостами, которые идентичны с точки зрения DDDS в части путей передачи полномочий, которые имеют некий общий набор свойств или административный домен.

5. Спецификация Базы данных

В дополнение к сказанному каждое Приложение должно иметь по крайней мере одну Базу данных, в которой отыскиваются Правила. Важно отметить, что данная База может использоваться и другими Приложениями. В таких случаях каждое правило должно использовать некую комбинацию своих служб (Service) и/или выражений для замены, соответствующую только той строке Application Unique Strings, для которой правило корректно.

Спецификация базы данных должна включать перечисленные ниже компоненты.

General Specification – общая спецификация

База данных должна иметь общую спецификацию, в качестве которой может использоваться ссылка на другой стандарт (SQL, DNS и т. п.) или полностью определенная новая спецификация. Спецификация Базы данных должна четко указывать допустимый набор символов, чтобы знать, какие наборы символов используются для представления Ключей и Правил.

Lookup Procedure – процедура поиска

Этот параметр задает способ формулировки и подачи запросов. В случае использования базы данных для других целей (например, DNS) спецификация должна ясно показывать, как формулируются запросы применительно к случаю DDDS. Например, База данных на основе DNS должна указывать используемые типы записей RR10 и запросов (Query).

Key Format – формат ключа

Если требуются какие-либо операции для преобразования Ключа во что-либо корректное для базы данных, такие преобразования должны быть четко определены. Например, в случае базы данных DNS Ключи должны создаваться как корректные доменные имена.

Rule Format – формат правила

Спецификация выходного формата для правила.

Rule Insertion Procedure процедура вставки правила

Спецификация вставки Правил в базу данных. Эта спецификация может включать политику, в соответствии с которой Правила могут или не могут добавляться в базу данных.

Rule Collision Avoidance – предотвращение конфликтов между правилами

Поскольку База данных может использоваться множеством Приложений (например, ENUM и URI Resolution), спецификация должна четко описывать способы предотвращения конфликтов между правилами. Обычно для решения этой задачи используются два метода: 1) запрет для одного ключа возможности быть корректным в двух разных Приложениях; 2) если вариант 1 невозможен, создается такое выражение для замены, чтобы регулярное выражение включало достаточную часть Application Unique String для идентификации различия между двумя Приложениями.

6. Примеры

Приведенные ниже примеры служат лишь для учебных целей. Рассмотренные приложения не специфицированы в каких-либо реальных документах.

6.1 Система идентификации автомобильных деталей

В этом примере рассматривается воображаемая система, в которой собраны воедино все производители автомобилей и используется стандартизованная система кодирования различных деталей (болты, гайки, шайбы, инструменты и т. п.), которая применяется в процессе производства и ремонта автомобилей. Проблема такого рода систем заключается в том, что автомобильная промышленность является сильно распределенной и многие детали производятся различными фирмами, расположенными по всему миру. Для того, чтобы найти информацию о какой-либо детали, система должна быть способна выяснить производителя этой детали и контактировать с ним.

Для облегчения задачи идентификационные номера выделяются как часть иерархической системы, в которой первые 5 цифр являются идентификатором производителя. Следующие 3 цифры идентифицируют линейку автомобилей (например, Ford, Toyota). Остальные цифры присваиваются производителями деталей по своему усмотрению.

Автомобильная промышленность приняла решение об использовании DDDS для создания распределенной системы поиска информации, которая маршрутизирует запросы к реальным держателям данных. Отрасль специфицировала базу данных и синтаксис запросов для отыскания правил перезаписи (APIDA Network) и Приложение Auto Parts Identification DDDS Application (APIDA).

Спецификация APIDA будет определять следующее:

  • Application Unique String – код детали;
  • First Well Known Rule – принимает первые 5 цифр (идентификатор производителя) и использует их в качестве Ключа;
  • Valid Databases — APIDA Network.
  • Expected Output – информация EDIFAC об интересующей детали.

Спецификация Базы данных APIDA Network будет определять следующее:

  • General Specification – сеть поддерживающих EDI баз данных и служб, которые по заданному субномеру детали будут возвращать правила перезаписи в формате XML;
  • Lookup Procedure – следует обычным протоколам APIDA Network, запрашивая в сети правило перезаписи для Ключа;
  • Key Format – преобразования не требуется;
  • Rule Format: см. документацию APIDA Network для XML DTD.
  • Rule Insertion Procedure – определяется агентством, которое контролирует каждую часть кодов деталей; например, для получения идентификатора производителя нужно быть членом Auto Parts Manufacturers Association.

В качестве иллюстрации рассмотрим деталь с кодом 4747301AB7D. Система будет брать первые 5 цифр 47473 и запрашивать в сети Правило перезаписи (Rewrite Rule). Это правило будет предоставляться базой данных о производителях деталей и позволит производителю передать полномочия далее или напрямую возвратить запрашивающему информацию EDIFAC.

Предположим для примера, что производитель возвращает Правило, которое говорит, что следующие 3 цифры нужно использовать как часть запроса к их сервису для получения нового Правила. Это новое Правило позволит производителю деталей передать полномочия на заводы по производству деталей для каждой линейки автомобилей. В нашем примере цифры 01A означают автомобили Toyota. Правило, которое возвращает производитель передает полномочия далее производителю в Японии. Это правило также означает, что данное Правило является завершающим и, таким образом, результатом последнего запроса будет информация о детали.

6.2 Служба идентификации документов

Этот пример напоминает предыдущий, поскольку документы в этой системе можно рассматривать аналогично автомобильным деталям. Различие состоит в том, что информация о документе хранится близко к его автору (обычно на его настольном компьютере). Это означает, что число передач полномочий может быть достаточно большим. Кроме того, для того, чтобы избавиться от необходимости поддержки большого плоского пространства авторов, они организованы по компаниям и подразделениям.

Предположим, что строка Application Unique String для данного примера имеет вид:

<organization>-<department>-<author>:<project>-<bookcase>-<book>

Спецификация приложения может выглядеть примерно так:

  • Application Unique String — приведенная выше строка идентификации документа;
  • First Well Known Rule – символы до (но не включая) “-” трактуются, как первый Ключ;
  • Valid Databases – каталог DIS LDAP;
  • Expected Output – запись с сервера LDAP, содержащая библиографические данные о документе в формате XML.

Спецификация базы данных для DIS LDAP Directory будет иметь вид:

  • General Specification – база данных использует службу каталогов LDAP; каждый сервер LDAP имеет запись, содержащую Правило перезаписи; правила указывают на другие серверы LDAP, используя схему LDAP URL;
  • Lookup Procedure – используя стандартные запросы LDAP, клиент спрашивает у сервера LDAP информацию о ключе;.
  • Key Format – преобразование не требуется;
  • Rule Format – см. спецификацию LDAP Rewrite Rule;
  • Rule Insertion Procedure – см. процедуры, опубликованные стороной, имеющей полномочия для данной ветви дерева DIS; первым разделом (организация) владеет Агентство DIS.

В этом примере первый поиск осуществляется по организации. В результате организация может может возвратить клиенту конечный результат, если база данных этой организации содержит его. В других случаях процесс может включать дополнительные Правила и делегировать запрос вниз по иерархии к владельцу документа.

7. Вопросы безопасности

Этот документ просто определяет алгоритм DDDS и, таким образом, сам по себе не оказывает влияния на безопасность. Когда алгоритм объединяется с Базой данных и Приложением, могут возникать связанные с безопасностью вопросы, одним из которых является возможность организации атак на динамические точки делегирования.

8. Согласование с IANA

Этот документ не создает каких-либо требований к IANA. Спецификации Баз данных и Приложений могут выдвигать такие требования, но они не рассматриваются здесь.

Литература

[1] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS», RFC 3401, October 2002.

[2] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.

[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[4] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application», RFC 3404, October 2002.

[5] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures», RFC 3405, October 2002.

[6] Moats, R., «URN Syntax», RFC 2141, May 1997.

[7] Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, January 1998.

[8] The Institute of Electrical and Electronics Engineers, «IEEE Standard for Information Technology — Portable Operating System Interface (POSIX) — Part 2: Shell and Utilities (Vol. 1)», IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.

[9] Mealling, M. and R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, August 2000.

[10] Faltstrom, P., «E.164 number and DNS», RFC 2916, September 2000.

[11] Daniel, R. and M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, June 1997.

Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

US

EMail: michael@neonym.net

URI: http://www.verisignlabs.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторский прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Dynamic Delegation Discovery System – динамическая система детектирования передачи полномочий.

2База данных DDDS.

3Uniform Resource Names – единообразные имена ресурсов.

4В оригинале — “chunks of syntax”. Прим. перев.

5Resolver Discovery Service – служба обнаружения преобразователей (имен).

6В оригинале — “ particular outcome”. Прим. перев.

7Extended Regular Expression

8В некоторых приложениях и/или базах данных результирующий набор может выражать случай, когда два или более Правила рассматриваются как эквивалентные. Такие Правила трактуются как одно Правило; каждое из возвращенных правил может иметь значение Priority, используемое для выбора предпочтительного Правила из набора эквивалентных. Это позволяет использовать Правило взамен другого при отказе того (fallbacks). Следует отметить, что этот механизм определяет предпочтения (Preference), а не распределение нагрузки. Приложениям следует аккуратно определять разницу.

Базы данных могут иметь (или не иметь) правила, которые определяют когда и как завершается срок корректности записей в базе (даты истечения срока, время жизни и т. п.). Эти механизмы должны применяться во всех случаях. В частности, поскольку завершение срока действия записи в базе может вынудить к поиску нового Правила, которое будет несовместимо с предыдущим Правилом, хотя в алгоритме любые попытки оптимизировать процесс путем возврата к предыдущим ключам и Правилам должны гарантировать, что срок действия ранее найденного правила не истек. Если срок действия Правила истек, приложение должно начать операции с п. 1.

9Domain Name System – система доменных имен.

10Resource Record – запись о ресурсе.




RFC 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS

Network Working Group                                    M. Mealling
Request for Comments: 3401                                  VeriSign
Updates: 2276                                           October 2002
Obsoletes: 2915, 2168
Category: Informational

Система DDDS. Часть 1 — DDDS в целом

Dynamic Delegation Discovery System (DDDS)

Part One: The Comprehensive DDDS

PDF

Статус документа

Этот документ содержит информацию для сообщества Internet и не задает каких-либо стандартов Internet. Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Тезисы

Этот документ точно определяет документы для полной спецификации системы DDDS1. Система DDDS представляет собой абстрактный алгоритм применения динамически отыскиваемых правил преобразования строк к уникальным строкам, связанным с приложением.

Данный документ вместе с RFC 3402, RFC 3403 и RFC 3404 отменяет документы RFC 2168 и RFC 2915, а также обновляет RFC 2276.

1. Аудитория

Этот документ вместе с упоминаемыми в нем документами предназначен для тех, понять и реализовать базовый алгоритм DDDS, преобразование URI Resolution, преобразование телефонных номеров ENUM в URI и DNS-записи NAPTR. Чтение отдельных документов этой серии без прочтения остальных может привести к непониманию и возникновению проблем интероперабельности.

2. Введение

Система DDDS используется для реализации простого связывания строк с данными, обеспечивающего поддержку динамически настраиваемых систем передачи полномочий (делегирования). DDDS отображает некие уникальные строки на данные, хранящиеся в DDDS Database2, путем итеративного применения правил преобразования строк, пока не будут достигнуты условия завершения. Этот документ определяет всю систему DDDS, перечисляя документы, образующие полную на данный момент спецификацию.

Этот документ вместе с RFC 3402, RFC 3403 и RFC 3404 отменяет действие RFC 2168 [8] и RFC 2915 [6], а также обновляет RFC 2276 [5]. При изменении спецификации DDDS данный документ будет обновляться или отменяться. Следовательно, читателю настоятельно рекомендуется проверять репозиторий IETF RFC на предмет появления документов, обновляющих или отменяющих данный документ.

3. Алгоритм

Алгоритм DDDS определен в RFC 3402 [1]. Этот документ определяет следующие концепции DDDS:

  • базовый лексикон DDDS;
  • алгоритм работы;
  • требования к приложениям, использующим алгоритм;
  • требования к базам данных для хранения правил DDDS.

RFC 3402 является актуальной спецификацией алгоритма DDDS. Однако спецификация сама по себе бесполезна без дополнительных документов, определяющих где и как используется алгоритм. Эти документы называются Приложениями (Application) и не являются частью основной спецификации DDDS. Приложения требуют баз данных для хранения их правил. Такие базы данных обозначаются термином DDDS Database и спецификации для них обычно указываются в отдельных документах. Эти документы также не являются частью основной спецификации DDDS.

4. Приложения DDDS

Ни одна реализация не может начаться без спецификации Приложения, поскольку именно эта спецификация обеспечивает конкретные детали для алгоритма DDDS. Без этого DDDS не представляет собой ничего, кроме общего алгоритма. Документы для Приложений определяют следующее:

  • Уникальная строка приложения (Application Unique String).
  • Первое общеизвестное правило (First Well Known Rule) – правило, говорящее где начинается процесс.
  • Список корректных баз данных (вы не можете просто использовать любую базу данных).
  • Ожидаемый в результате вывод данных.

Примерами документированных Приложений могут служить:

  • E.164 number and DNS (RFC 2916) [7]. Это Приложение использует DDDS для отображения телефонных номеров на конечные точки сервиса типа SIP или электронной почты.
  • Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application (RFC 3404) [3]. Это Приложение использует DDDS для преобразования любого URI в набор конечных точек или «преобразователей» (resolver), которые дают дополнительную информацию об URI независимо от конкретной схемы URI.

5. Стандартизованные базы данных

Любое Приложение DDDS должно использовать тот или иной тип базы данных (DDDS Database). Документы для баз данных определяют следующее:

  • общие спецификации работы базы данных;

  • форматы для ключей ((Key);
  • форматы для правил (Rule);
  • процесс поиска ключей;
  • процедуры вставки правил;
  • методы предотвращения конфликтов.

База данных не может использоваться сама по себе – должно существовать хотя бы одно Приложение, которое ею пользуется. Определено множество Баз данных и Приложений и некоторые Базы будут поддерживать множество Приложений. Однако не каждое Приложение использует каждую Базу данных (и наоборот). Таким образом, соответствие спецификациям определяется для пары Приложение – База данных.

Одним из примеров спецификации Базы данных является:

  • Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database (RFC 3402) [1]. (этот документ содержит официальную спецификацию записи NAPTR в DNS).

6. Вопросы безопасности

Любые проблемы безопасности, которые могут быть связаны с использованием алгоритмов и баз данных, должны быть описаны в соответствующих спецификациях. Проблемы должны быть описаны полностью. Не требуется, чтобы база данных или алгоритм были защищенными, или свободными от риска, но все известные проблемы и риски должны быть указаны. Публикация нового типа базы данных или алгоритма требует обзора безопасности и тема безопасности должна быть предметом постоянного изучения. Дополнительные вопросы безопасности следует решать путем публикации пересмотренной версии спецификации алгоритма или базы данных.

7. Согласование с IANA

Хотя сам этот документ не создает каких-либо новых требований для IANA, другие документы этой серии порождают множество требований. Разделы «Согласование с IANA» (IANA Considerations) в этих документах должны просматриваться агентством IANA для определения полного набора новых реестров и требований. Любым новым алгоритмам, базам данных и приложениям следует аккуратно учитывать, что они могут требовать от IANA в будущем.

Литература

[1] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.

[2] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Doman Name System (DNS) Database», RFC 3403, October 2002.

[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application», RFC 3404, October 2002.

[4] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures», RFC 3405, October 2002.

[5] Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, January 1998.

[6] Mealling, M. and R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, August 2000.

[7] Faltstrom, P., «E.164 number and DNS», RFC 2916, September 2000.

[8] Daniel, R. and M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, June 1997.

Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

US

EMail: michael@neonym.net

URI: http://www.verisignlabs.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Dynamic Delegation Discovery System – динамическая система детектирования передачи полномочий.

2База данных DDDS.

3На сайте www.protocols.ru имеется перевод этого документа на русский язык. Прим. перев.