RFC 2680 A One-way Packet Loss Metric for IPPM

Network Working Group                                           G. Almes
Request for Comments: 2680                                  S. Kalidindi
Category: Standards Track                                   M. Zekauskas
                                             Advanced Network & Services
                                                          September 1999

A One-way Packet Loss Metric for IPPM

Метрика потерь в одном направлении для IPPM

PDF

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

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

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

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

1. Введение

Этот документ определяет метрику задержки в одном направлении на путях Internet. Метрика основана на концепциях, введённых и рассмотренных в документе IPPM Framework RFC 2330 [1]. Предполагается, что читатель знаком с этим документом.

Документ аналогичен по структуре документу, определяющему метрику потерь в одном направлении (A One-way Delay Metric for IPPM) [2], с которым читателю также следует ознакомится.

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

Структура документа описана ниже.

• Вводится одиночный (singleton) аналитический показатель Type-P-One-way-Packet-Loss¹ для однократного наблюдения потерь в одном направлении.

• С использованием этого показателя определяется выборка (sample) Type-P-One-way-Loss-Poisson-Stream для последовательности одиночных измерений односторонних потерь в соответствии с выборкой Пуассона.

• С использованием выборки определяется и рассматривается статистика.

Такой переход от одиночных измерений через выборки к статистике с их чётким разделением имеет важное значение.

Когда в этом документе первый раз используется термин из IPPM Framework, он помечается звёздочкой в конце. Например, term* указывает термин term, определённый в IPPM Framework.

1.1. Мотивация

Знать потери пакетов Type-P* в одном направлении от хоста-источника (host*) к хосту-получателю полезно по нескольким причинам.

• Некоторые приложения не работают хорошо (или совсем), если сквозные потери между хостами превышает определённый порог.

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

• Чем больше потери, тем сложнее протоколам транспортного уровня поддерживать высокую пропускную способность.

• Зависимость приложений в реальном масштабе времени или транспортных протоколов от потерь становится особенно важной, когда требуется поддержка приложений с очень большим произведением «задержка * пропускная способность» (delay-bandwidth).

Измерение потерь в одном направлении вместо измерения круговых потерь обусловлено несколькими факторами.

• В современной сети Internet путь от источника к получателю может отличаться от обратного пути (асимметрия путей) так, что на прямом и обратном пути будут использованы разные цепочки маршрутизаторов. Поэтому при измерении круговых параметров фактически объединяются измерения для двух разных путей. Независимое измерение на каждом из путей позволяет увидеть различия в их производительности, при этом пути могут проходить через разных провайдеров Internet и даже использовать разные технологии (например, исследовательские и коммерческие сети, ATM и packet-over-SONET).

• Даже при симметричном пути направления могут существенно различаться, например из-за асимметричных очередей.

• Производительность приложения может сильнее зависеть от производительности в одном из направлений. Например, при копировании файлов по протоколу TCP важнее производительность в направлении потока данных, а не подтверждений доставки.

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

Применение метрики измерения потерь в конкретных ситуациях выходит за рамки этого документа.

1.2. Общие вопросы, связанные со временем

{Комментарий. Приведённые ниже термины отличаются от определений в документах ITU-T (например, G.810 «Definitions and terminology for synchronization networks» и I.356 «B-ISDN ATM layer cell transfer performance»), но согласуются с документом IPPM Framework. В общем случае эти различия обусловлены разным контекстом, документы ITU-T исторически связаны с телефонией, а авторы этого документа (и IPPM Framework) работают с компьютерными системами. Хотя определённые ниже термины не имеют прямых эквивалентов в определениях ITU-T, ниже приведены приблизительные (грубые) сопоставления. Однако следует отметить возможный конфликт — приведённое здесь определение часов (clock) относится к компьютерной операционной системе и текущему времени суток, а clock в определении ITU-T указывает эталонную синхронизацию.}

При упоминании в документе времени (т. е. момента в истории) имеется в виду значение в секундах (и долях) для часового пояса UTC.

Как описано в документе IPPM Framework, есть 4 разных, но связанных понятия неопределённости часов (времени).

synchronization* — синхронизация

Степень согласованности часов в части текущего времени. Например, часы одного хоста могут опережать часы другого на 5,4 мсек. {Комментарий. Грубый эквивалент ITU-T — time error.}

accuracy* — точность

Степень соответствия данных часов времени UTC. Например, часы хоста могут отставать от UTC на 27,1 мсек. {Комментарий. Грубый эквивалент ITU-T — time error from UTC.}

resolution* — разрешение (дискретность)

Наименьшая единица, на которую могут изменяться показания часов. Это определяет нижнюю граничу неточности часов. Например, часы в старых системах Unix могут «тикать» лишь каждые 10 мсек, поэтому они будут иметь дискретность 10 мсек. {Комментарий. Очень грубый эквивалент ITU-T — sampling period.}

skew* — перекос

Мера изменения точности или синхронизации с течением времени. Например, часы хоста могут отставать на 1,3 мсек за час и отставать на 27,1 мсек от UTC в данный момент, а через час они будут отставать от UTC лишь на 25,8 мсек. В этом случае мы говорим, что часы данного хоста имеют перекос в 1,3 за час относительно UTC в плане точности. Можно также говорить о перекосе одних часов относительно других в плане синхронизации. {Комментарий. Грубый эквивалент ITU-T — time drift.}

2. Одиночное измерение односторонних потерь

2.1. Название показателя

Type-P-One-way-Packet-Loss

2.2. Параметры метрики

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

T

Время.

2.3. Единицы измерения

Значением показателя Type-P-One-way-Packet-Loss является 0 (успешная передача пакета) или 1 (пакет потерян).

2.4. Определение

Нулевое значение Type-P-One-way-Packet-Loss при передаче от Src к Dst в момент времени T означает, что хост Src передал первый бит пакета Type-P хосту Dst в момент времени в линии (wire-time*) T и хост Dst получил этот пакет.

Значение 1 для Type-P-One-way-Packet-Loss от Src к Dst в момент T означает, что хост Src передал первый бит пакета Type-P по адресу Dst в момент времени в линии T, но пакет не пришел к Dst.

2.5. Обсуждение

Type-P-One-way-Packet-Loss имеет значение 0, когда задержка Type-P-One-way-Delay имеет конечное значение, и 1 при неопределённой (бесконечной) задержке Type-P-One-way-Delay.

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

• Методика должна включать способ определения, является потерей пакетов и очень большой (но конечной) задержкой. Как отметили Mahdavi и Paxson [3], можно использовать простую верхнюю границу (например, теоретическое ограничение срока существования пакетов IP в 255 секунд [4]). Но на практике требуется понимать сроки существования пакетов.

  {Комментарий. Отметим, что для многих применений этого показателя негативное влияние трактовки очень большой задержки как потери, может отсутствовать или быть совсем незначительным. Например, голосовой пакет, полученный после момента его воспроизведение, можно считать потерянным.}

• Если пакет прибывает повреждённым, он считается потерянным.

  {Комментарий. Возникает искушение считать повреждённые пакеты полученными, поскольку повреждение и потеря пакета — связанные, разные события. Однако при повреждении заголовка IP нет уверенности в IP-адресах отправителя и получателя и, следовательно, в том, что это именно тестовый пакет. Если при других повреждениях можно сопоставить повреждённый пакет с отправленным тестовым пакетом и считать его полученным, это приведёт к несогласованности.}

• Если пакет дублируется в пути (путях) и к получателю приходит несколько неповреждённых копий, пакет считается полученным.

• Если пакет фрагментирован и по какой-то причине сборка не выполняется, пакет считается потерянным.

2.6. Методики

Как и для иных показателей Type-P-*, конкретная методика будет зависеть от Type-P (например, номера протокола, порта UDP/TCP, размера).

В общем случае для данного Type-P методика будет действовать, как указано ниже.

• Выполняется синхронизация Src и Dst, чтобы их часы указывали достаточно близкое и точное время. Точность синхронизации является параметром метода и связана с порогом определения потерь (см. ниже).

• На хосте Src выбираются IP-адреса Src и Dst и создаётся тестовый пакет Type-P с этими адресами.

• На хосте Dst организуется приём пакета.

• На хосте Src в подготовленный пакет Type-P помещается временная метка и пакет передаётся в направлении Dst (в идеале с минимальной задержкой отправки).

• Если пакет прибывает в течение разумного интервала времени, считается Type-P-One-way-Packet-Loss = 0.

• Если пакет не прибывает в течение разумного интервала времени, считается Type-P-One-way-Packet-Loss = 1. Отметим, что значение «разумного интервала» здесь является параметром методики.

  {Комментарий. Определение разумного интервала осознанно является нестрогим и обозначает значение Th, достаточно большого для того, чтобы любое значение из интервала [Th-delta, Th+delta] было эквивалентно порогу потери. Значение delta здесь учитывает ошибку синхронизации часов на пути измерения. Если имеется одно значение, по достижении которого пакет должен считаться потерянным, снова вводится необходимость синхронизации часов как при измерении односторонней задержки. Если требуется мера потери пакетов, параметризованная конкретным (не чрезмерно большим) значением «разумного интервала» ожидания, можно измерить одностороннюю задержку и посмотреть, какая часть пакетов данного потока выходит за этот интервал.}

Такие вопросы, как формат пакета, способы, с помощью которых Dst узнает, когда следует ждать тестовый пакет, а также способы синхронизации Src и Dst выходят за рамки этой спецификации. {Комментарий. Планируется более подробно документировать методы реализации работы авторов в другом документе и другим также рекомендуется делать это.}

2.7. Ошибки и погрешности

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

• ошибки и погрешности часов на хостах Src и Dst;

• пороговое значение фиксации потери (связано с синхронизацией часов);

• ограничения ресурсов сетевого интерфейса и программ на приёмном оборудовании.

Первые два источника ошибок связаны между собой и могут приводить к признанию потерянным тестового пакета с конечной задержкой. Type-P-One-way-Packet-Loss = 1², если тестовый пакет не приходит или приходит с разницей временных меток Src и Dst, превышающей «разумный интервал» или порог потерь. Если часы не синхронизированы точно, порог потерь может оказаться «неразумным», т. е. фактическое время доставки пакета будет существенно меньше определённого из метки Src. Если установлен слишком низкий порог потерь, многие пакеты будут сочтены потерянными. Порог потерь должен быть достаточно большим, а синхронизация — достаточно точной, чтобы прибывшие пакеты не считались потерянными слишком часто (см. обсуждение в двух предыдущих параграфах).

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

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

Измерительные устройства следует калибровать так, чтобы порог потерь был приемлемым для применения показателей, а часы синхронизированы достаточно точно, чтобы порог оставался разумным. Кроме того, измерительные устройства следует проверять на предмет обеспечения малой вероятности трактовки пакетов, отброшенных измерительным устройством из-за нехватки ресурсов (например, буферов), как потерянных.

2.8. Отчёты об измерениях

Калибровка и контекст выполнения измерений должны тщательно рассматриваться и их следует включать в отчёт вместе с измеренными значениями. Далее представлены 4 элемента, которые следует включать в отчёт: Type-P для тестовых пакетов, порог бесконечной задержки (при наличии), калибровка ошибок и путь, по которому проходят пакеты. Список не является исчерпывающим и следует включать в отчёт любые дополнительные сведения, которые могут быть полезны при интерпретации показателей.

2.8.1. Type-P

Как указано в документе IPPM Framework [1], значение показателя может зависеть от типа пакетов IP, применяемых для измерений — Type-P. Значение Type-P-One-way-Delay может меняться при смене протокола (UDP или TCP), номера порта, размера пакетов или особых условий (например, поле предпочтений IP или RSVP). В отчёт должно включаться точное указание Type-P при измерениях.

2.8.2. Пороговое значение потерь

В отчёт должно включаться пороговое значение (или метод) для различия конечной задержки и потери.

2.8.3. Результаты калибровки

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

2.8.4. Путь

В отчёте следует по возможности указывать путь, по которому проходят пакеты. В общем случае сложно узнать точный путь, по которому данный пакет прошёл через сеть. Точный путь может быть известен для некоторого Type-P на коротком и стабильном участке. Если Type-P включает опцию записи маршрута (или loose-source route) в заголовке IP, путь достаточно короток и все маршрутизаторы (router*) на пути поддерживают опцию source route (или loose-source route), путь будет записан точно. Это непрактично, поскольку требует достаточно короткого пути, многие маршрутизаторы не поддерживают опцию записи маршрута (или она отключена), а применение этого свойства зачастую снижает производительность. Однако частичные сведения о пути обеспечивают значимый контекст. Например, если хост может выбирать между двумя каналами (link*) и, следовательно, двумя разными маршрутами от Src к Dst, используемый канал обеспечивает значимый контекст. {Комментарий. Например в Merit NetNow Src, являющийся одной из точек доступа в сеть (Network Access Point — NAP) может достичь Dst в другой точке NAP по любой из сетевых магистралей.}

3. Определение выборки для односторонних потерь

На основе одиночной (singleton) метрики Type-P-One-way-Packet-Loss определим конкретную выборку таких одиночных измерений. Идея выборки (sample) заключается в отборе конкретной связки параметров Src, Dst, Type-P и определении выборки значений параметра T. Способ определения значений T состоит в выборе начального (T0) и конечного (Tf) времени, а также средней частоты lambda и последующем задании псевдослучайного процесса Пуассона со скоростью lambda в интервале от T0 до Tf. Интервал времени между последовательными значениями T имеет среднее значение 1/lambda.

{Комментарий. Отметим, что выборка Пуассона является лишь одним из вариантов выборки. Преимуществом её является ограничение смещения (bias), но в других ситуациях могут оказаться лучше иные методы выборки. Предлагается при нахождении таких вариантов использования общей схемы представлять методы выборки для стандартизации.}

3.1. Название показателя

Type-P-One-way-Packet-Loss-Poisson-Stream

3.2. Параметры метрики

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

T0

Время (начала).

Tf

Время (завершения).

lambda

Число измерений в секунду.

3.3. Единицы измерения

Последовательность пар (T, L), где T указывает время, а L имеет значение 0 или 1. Значения T в последовательности измерений возрастают монотонно. Отметим, что параметры T и L действительны также для метрики Type-P-One-way-Packet-Loss.

3.4. Определение

На основе T0, Tf и lambda рассчитывается псевдослучайный процесс Пуассона, начинающийся не позже T0, включающий среднюю частоту прибытия пакетов lambda и завершающийся не раньше Tf. Значения времени выборки относятся к диапазону от T0 до Tf. В каждый из выбранных моментов измеряется одно значение Type-P-One-way-Packet-Loss. Значением выборки является последовательность пар (время, потери). Если таких пар нет, последовательность имеет размер 0 и выборка считается пустой.

3.5. Обсуждение

Читателю следует ознакомиться с углублённым обсуждением выборки Пуассона в документе IPPM Framework [1], где рассмотрены методы расчёта и проверки псевдослучайных пуассоновских процессов.

Значение lambda осознанно не ограничивается за исключением указания крайних точек. Если частота слишком велика, тестовый трафик будет нарушать работу сети и сам вызывать перегрузки. При слишком малой частоте могут быть упущены некоторые интересные детали поведения сети. {Комментарий. Предполагается описать опыт и предложения для значений lambda в отдельном документе серии BCP.}

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

Выборка определяется как пуассоновский процесс, чтобы избежать самосинхронизации и обеспечить выборку, статистически наиболее достоверную (unbiased). Пуассоновский процесс служит для планирования измерений задержки. Тестовые пакеты в общем случае не будут приходить на Dst в соответствии с распределением Пуассона, поскольку сеть оказывает влияние на их доставку.

{Комментарий. Конечно не принимается допущений о том, что реальный трафик Internet прибывает в соответствии с распределением Пуассона.

Важно отметить, что в отличие от данной метрики, частота потерь, фиксируемая транспортными соединениями, не отражает несмещенные (unbiased) выборки. Например, для передач TCP (1) характерны пики трафика, которые могут вызывать потери, не наблюдающиеся в других ситуациях и (2) скорость изменяется в попытке минимизировать возникающие в соединении потери.}

Все одиночные (singleton) показатели Type-P-One-way-Packet-Loss в последовательности измерений будут иметь одни значения Src, Dst, Type-P.

Отметим также, что данная выборка с момента T0 до Tf и субпоследовательность от T0′ до Tf’, где T0 <= T0′ <= Tf’ <= Tf, также будет действительной выборкой Type-P-One-way-Packet-Loss-Poisson-Stream.

3.6. Методики

Методика включает указанные ниже действия.

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

• Методика, рассмотренная для одиночного (singleton) измерения Type-P-One-way-Packet-Loss.

Следует корректно обрабатывать нарушения порядка прибытия тестовых пакетов. Src может передать тестовый пакет в момент TS[i], а затем передать следующий в момент TS[i+1], при этом Dst может получить сначала второй пакет в момент TR[i+1], а позднее — первый в момент TR[i].

3.7. Ошибки и погрешности

В дополнение к ошибкам и погрешностям, связанным с методом одиночных измерений, входящих в выборку, необходимо тщательно проанализировать точность процесса Пуассона в части времени в линии при отправке тестовых пакетов. Проблемы в этом процессе могут быть связаны с несколькими обстоятельствами, включая метод генерации псевдослучайных чисел для процесса Пуассона. В документе IPPM Framework показано, как использовать тест Anderson-Darling для проверки точности пуассоновского процесса в коротких интервалах времени. {Комментарий. Цель состоит в передаче тестовых пакетов «достаточно близко» к планированию Пуассона без возникновения периодической отправки.}

3.8. Отчёты об измерениях

Калибровка и контекст для одиночных измерений должны указываться в отчёте (см. 3.8. Отчёты об измерениях).

4. Определения статистики для односторонних потерь

На основе выборки Type-P-One-way-Packet-Loss-Poisson-Stream предлагается несколько вариантов статистики. Описание статистики служит в основном для иллюстрации того, что можно сделать.

4.1. Type-P-One-way-Packet-Loss-Average

Для данной выборки Type-P-One-way-Packet-Loss-Poisson-Stream усредняются значения L в потоке. Кроме того, Type-P-One-way-Packet-Loss-Average будет неопределённым для пустой выборки.

Предположим в качестве примера выборку, показанную ниже.

      Stream1 = <
      <T1, 0>
      <T2, 0>
      <T3, 1>
      <T4, 0>
      <T5, 0>
      >

Среднее значение составит 0,2.

Отметим, что «здоровые» пути Internet должны иметь потери меньше 1% (особенно при высоких значениях произведения задержки на пропускную способность (delay-bandwidth)), поэтому могут потребоваться выборки большого размера. Например, для определения потерь в доли процента с течение минуты может потребоваться несколько сотен выборок в минуту. Это ведёт к большим значениям lambda.

Хотя порог потерь следует устанавливать так, чтобы минимизировать ошибки при учёте потерь, возможны случаи, когда прибывшие пакеты будут считаться потерянными в результате нехватки ресурсов. Если такие «потери» велики, измерение Type-P-One-way-Packet-Loss-Average теряет смысл.

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

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

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

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

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

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

Спасибо Matt Mathis за поддержку этой работы и привлечение внимания к вопросам измерения потерь пакетов.

Спасибо Vern Paxson за ценные комментарии к ранним вариантам документа, а также Garry Couch и Will Leland за полезные предложения.

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

[1] Paxson, V., Almes,G., Mahdavi, J. and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[2] Almes, G., Kalidindi, S. and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, September 1999.

[3] Mahdavi, J. and V. Paxson, «IPPM Metrics for Measuring Connectivity», RFC 2678, September 1999.

[4] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

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

[6] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, October 1996.

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

Guy Almes

Advanced Network & Services, Inc.

200 Business Park Drive

Armonk, NY 10504

USA

Phone: +1 914 765 1120

EMail: almes@advanced.org

 

Sunil Kalidindi

Advanced Network & Services, Inc.

200 Business Park Drive

Armonk, NY 10504

USA

Phone: +1 914 765 1128

EMail: kalidindi@advanced.org

 

Matthew J. Zekauskas

Advanced Network & Services, Inc.

200 Business Park Drive

Armonk, NY 10504

USA

Phone: +1 914 765 1112

EMail: matt@advanced.org

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

Copyright (C) The Internet Society (1999). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

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

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

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

nmalykh@protokols.ru